<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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
