Re: Freemarker support

[Jonathan Revusky <jo...@revusky.com>]

Quinton McCombs wrote:

<snip>

>>I think you can definitely say that 
>>the emphasis 
>>on Velocity and the coupling you refer to was not something that came 
>>about based on purely technical considerations.
> 
> 
> Hmmm...  Interesting history.  I can see how that might have happened.
> Just like you like to actively promote your project, it would make
> perfect sense that Jon, perhaps, saw no reason to provide robust support
> for anything besides Velocity.  In his eyes, and probabley many other at
> the time, Velocity was _the_ answer.  

Well, they wanted people to perceive Velocity as _the_ (sole) answer.

> 
> You are correct about the WebMacro stuff.  There is still comments in
> the code used for Velocity support indicating the the code was
> originally copied from a WebMacro version and adpated for Velocity.  It
> is rather clear which came first.

This is well known.

>  
> 
>>I understand perfectly well that you and Henning had nothing 
>>to do with 
>>all this. Of course, given that, I don't see why you feel the 
>>slightest 
>>need to defend any of the prior foolishness.
> 
> 
> Perhaps it does come across as defensiveness.

Well, I earlier made rather harsh comments about saving the energy
expended in bullshitting one another. They're harsh comments, but I
think they apply in this instance.

There is no particular reason for you to try to come up with 
rationalizations for bonehead decisions that you were not part of. It is 
a waste of energy.

>  We just did not agree
> with your conclusion of why support was removed.  You seemed to take it
> as a negative reflection on the quality or robustness of your product.
> Consider for a moment that perhaps that was not the case.  

Not to worry. I never took it as a negative reflection on the quality or
robustness or our product. And why would I? For one thing, the extremely 
obsolete version of FM you were supporting was not even my work. I have 
been the main developer in all the FreeMarker 2.x cycles -- 2.0, 2.1, 
2.2, and now 2.3. The version of FM you were supporting was 1.5.2, I 
think. Also, by people's own admission, they never even looked at 
current versions of FreeMarker when deciding to remove support.

> 
> If it was really because it was so badly implemented within Turbine,
> there were almost no active developers or contributors at the time, a
> generaly lack of knowledge reguarding the improvements in FM, etc.....  

Well, again, in the above, there seems to be an attempt to put spin on 
things. I think you should refrain from that.

The fact remains that if you (or whoever) lacked knowledge about what 
was going on in FM, that was really by your own choice, wasn't it?

I mean, why didn't anyone look at the FreeMarker website and make some
comparisons? Why was the decision made to remove FM support (as opposed
to bringing it up-to-date) in favor of Velocity without comparing the
state of the 2 tools and the underlying development efforts?

The above are not accusations. They are questions that only the
people involved can answer.

Now, my take on this is that there is something of a "we are the world" 
sort of bias in Jakarta/ASF culture. It really is a bit like non-ASF 
projects don't quite really exist for you guys. That bias would explain 
why a decision was made to remove FM support (as opposed to making the 
minimal effort to keep it up-to-date) *without* even looking at the 
state of the project.

> 
> Since this is one of the points that seemed to offend you, I just want
> you to consider that maybe there were good reasons for dropping support.
> Granted the argument of "it's being used by anyone" was invalid because
> the support was so poor that no one could use it.  However, that might
> not have been the motivating reason.  

> 
> Like I have said earlier, I like what I see in your product.  I would
> very much like to see support for FM in Turbine.  Personally, I do not
> really like velocity.  However, since nothing else is supported with
> Turbine very well, I am forced to deal with it.  

Well, this is a problem, and I think it is damaging to Turbine at this
point.

> 
> Given that I would like to see support for FM in Turbine, it becomes
> beneficial to have a good relationship with the developers of FM.  This
> is the reason that I am taking the effort to explain all of this.  I
> would hope that once one of us has the time to start looking into
> supporting FM, that we will be able to get assistance when it becomes
> needed.

Well, there is no particular cause for concern here. The FM community
really is pretty responsive when people ask for help on this kind of thing.

<snip>

> There are other services which are tightly coupled with out Velocity
> service as well.  This is really where Hennning has been doing a great
> deal of clean up work.  He is probabley correct about it being a
> significant level of effort to provide all of the fucntionality that we
> currently have with Velocity in FM.  
> 
> I am not as familiar with that code as he is.  Perhaps it will not be as
> big of a deal as it might seem at just the first look.  I do intend on
> looking into this myself since I am interested in trying out FM.

My own experience is that supporting multiple template engines from a
web app framework tends to be rather trivial.

<snip>
> 
> 
> If we provide FM support before we rework the view integration code,
> there might not be much work needed at all.  The only thing that is
> unclear to me is how we will provide for pull tools in FM.  Without
> digging through the docs, perhaps you can shed a little light on this.

What is a "pull tool"? You mean you just expose a javabean to the
context and you invoke methods on it? Well, you can do that perfectly
well from FM.

> 
> Our pull service allows you to write tools that are available for use
> inside of the template.  The tools are initialized and put into the
> Velocity context.  On the template, the tools are referenced by some
> configurable name like $link.  To Create a URL using this tool the code
> looks something like $link.setPage("myPage.vm").  
> 
> I userstand that you do expose java object to the template but not by
> using reflection.  Could you briefly explain how my javabean used in the
> previous example would work in FM?

See:

http://freemarker.org/docs/pgui_misc_beanwrapper.html

You can expose an object with full reflection if you want.

>  
> 
>>These are the 2 basic things that got my back up:
>>
>>1. This stuff about everybody having chosen Velocity and 
>>nobody wanting 
>>FM -- this seems very dishonest to me, because the two things 
>>were never 
>>competing on an equal footing. It's a contrived argument based on a 
>>rigged situation.
> 
> 
> But I think your problem with it seemed to revolve around the belief
> that it was rigged make a competing product look better than yours.  It
> certainly was not a fair question to ask the users for obvious reasons.
> However, as I stated earlier, perhaps there was nothing underhanded
> going on at all.

Maybe not consciously. However, the end result of this is annoying. You 
have to look it from my POV a bit, and that of the FM camp. We  are 
"competing" with Velocity, which is *extremely* inferior technology at 
this point. OTOH, I have little doubt that Velocity still has more users 
than FM. Why?

Placement.

Fine. Why do all the Turbine users use Velocity and not FM? Did they
really choose Velocity?

No, of course not. It was placement. We all know this. There are no 
recriminations really. However, to start claiming that everyone is using 
Velocity because they chose that... that's a bit much. But I have now 
heard several times, things like:

"Everybody chose Velocity and is happy with it, so there is no point in 
offering our users a choice." (*)

Now, I specifically asked Henning Schmiedehausen how he, in my position, 
would react to people laying this bullshit on him? (Because it *is* 
bullshit, and not only is it bullshit, but it's pretty obvious.)

Rather than answer the question, he then engaged in a lot of what can 
only be characterized as phony posturing about what a terrible guy I am 
-- basically to avoid answering the question. Some other poster then 
claimed (quite falsely) that I had questioned Henning's technical skill 
level (????!!!!) and thus, Henning's diatribe was justified. Supposedly, 
I was guilty of all kinds of ad-hominem attacks.

<shrug>

I don't really want to rehash all that, but you can understand that I am 
getting _tired_. People may perceive that I'm on edge here, but it may 
well boil down to this feeling of mine that I'm dealing with people who 
don't play fair -- people who like to play a rigged game, stack the deck 
-- and generally, do not have the high respect for the truth that 
engineering/technical sorts of people ought to have.

Actually, I would like you to answer the question, Quinton. If you were 
in my shoes, how would you feel in that situation when somebody comes 
out with the above? (*) above.

I would also appreciate if Henning answered the question. It was a 
good-faithed question and I think it deserves a response.

> 
>>2. The implicit idea that I am the one in a supplicant 
>>position asking 
>>*you* for something.  "If you want the FM support in there, submit a 
>>patch". 
> 
> 
> Come on now.  This is a common first reaction from many OSS
> developers.... Granted, it is usually the wrong response.

In this case, I think it really was. Given the history of this whole
situation, it is quite something for someone in my position to swallow.

> 
> 
>>Quite literally, there seems to be this idea that, by 
>>leveraging 
>>*our* community's hard work, you are doing *us* a favor. You can deny 
>>that this was ever insinuated, but I have inferred this subtext.
> 
> 
> Maybe that is what he meant.  Maybe it was not.  Perhaps he simply
> thought that you were asking for support to be added and so he offered
> to let you implement it.  There could have been a misunderstanding on
> both sides.

Well, I never asked for support to be added. Henning broached the 
possibility in a dialogue on another list.

Now, I think that, in this culture, there is some tendency just to 
automatically assume that I must be the one asking you guys for 
something. It's a cultural assumption of some sort.

There are a lot of things that you guys probably are not even doing 
consciously, but are extremely obnoxious and provocative. However, you 
don't perceive how obnoxious and provocative you are, you think you're 
really nice mild-mannered guys, so I must be the aggressor. Something 
like that.... there is an incredible perception gap here, stepping back 
from this a sec, it's actually quite an interesting sociological 
phenomenon....

> 
> 
>>To be brutally honest, Turbine gains a lot more from FM 
>>integration than 
>>we do. You say you've looked through the FM docs, so I think you know 
>>that what I'm saying is true. And the truth should be 
>>something that is 
>>respected.
> 
> 
> The real truth is that we both have something to gain.  You get a little
> more wider acceptance.  We get to offer our users more freedom in
> implementing the view layer.  Perhaps even a more powerful and robust
> option.

We both gain, and, yes, I do prefer for Turbine to support FM than for
it not to support FM.

But anyway, Quinton, I commend you. On this: You are the first guy here 
who seems to have recognized that I (the FM community really) have a lot 
to offer you. And thus, I guess you realize that it makes sense to 
behave in a somewhat humble, respectful way.

Other people just don't realize that...

Rudeness: "Hey, submit a patch and stop spamming us."

Silliness: "You're a bad guy and, you know what, we might not use your 
work, because you're such a bad guy..."

There are people in your community who have to open their eyes and 
realize that there is a world out there, there is a logic and structure 
to things, and... you know... behave more in accordance with that...

Regards,

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org