Jason Foster wrote: > > The golden rule to avoid FS is: give users all the freedom they need, > > but no more than that. > > > > This is what we did for the sitemap and even it's entirely possible for > > you to write your sitemap by hand in java, I don't know of anybody who > > did it. > > I would hazard that the rest of the Cocoon plumbing made that > infeasibly difficult. It's hard to know where the sitemap stops and > Cocoon starts (and what are EventPipelines anyways!?).
What makes you think that a flowmap would be less hard to write by hand? or with a strategy that was not built ad-hoc for it? > > Don't get me wrong: you know how much I like modularity, > > componentization and polymorphism, but I don't like to give users more > > freedom than what they need because, otherwise, we'll end up having to > > maintain and support all that freedom, wasting precious resources to > > improve what we find out to be the best strategy. > > This is where my "pseduo-postmodern" instincts start to twitch. The > whole notion of a "best strategy" strikes me as being a little too > simplistic. I'm thinking back now to your RT on caching from so long > ago. As I understood your proposal, you were advocating a cache that > was in large part self-tuning. You also allowed for developers (and > users) to choose which optimization function to use. One could argue > that allowing different optimization functions was FS. Absolutely. This is what RT are for: gather consensus and share visions on what is needed and what is pure esthetic abstraction. If you and I have different FS alarms but both don't ring on a solution, I personally have the impression that this solution is better than one that makes one or the other alarm ringing, don't you think? Some 5 years ago, I thought that more freedom you give to a program, the better. Then I met the design patterns metapattern: there are guidelines that 'guide' you and distill the experience of many brilliant people before you. By using them, you are not limiting your freedom, you are avoiding those rocky roads that would slow you down anyway. I believe that semantics are patterns: I'd rather spend time improving the patterns and distill more and more working knowledge into them, rather than making it easier to people to try new ones out. > BTW, it was a *really cool* approach to caching. Thanks, but probably too difficult to understand. Which is the reason why only a third was implemented. > Anyways, the notion of "best strategy" for modeling a webapp depends > on a whole ton of factors like: > > - what model are developers familiar with (if adoption is the key) > - what model is most straightforward (to who?) > - what model is the least verbose (if size matters) > - what model makes the fewest demands on the programmer/architect/... > - what model is most maintainable > - what model requires the most supporting tools > > I'm concerned that as we satisfice (which, don't get me wrong, is a > good thing) we are going to prevent Cocoon from become the "Avalon of > the Web Publishing World". Avalon, as I understand it, doesn't > enforce much of a conceptual model on the developer. It does have > one, but it is nice and generic and as such doesn't constrain > developers. :) Here is where you miss my entire point: Avalon is *very* strict. It forces you to follow a behaviorally-based model based on IoC and SoC. If you think this framework doesn't limit you, this means that we, the Avalon architects, succeeded: in fact it does, but it does so in such a way that you would go in that direction anyway (in fact, once they learned Avalon, people tend to use Avalon it all over their projects!) If you don't have this impression with Cocoon, this doesn't mean that the 'pattern' of limiting your freedom to the strictly needed is a bad one, but simply that Cocoon is not yet architecturally advanced enough for your needs. Avalon stands to Java (for server programming) like Cocoon stands to servlets (for web publishing). You have expressed your vision on Cocoon indicating that you don't see the sitemap as a strong enough concept to be included into those "core" patterns that Cocoon proposes. I tend to agree (even if I think it's a giant step in the right direction). I have the impression than once the sitemap is coupled with the flowmap, you might think the opposite and find yourself in the same good perception that Avalon gives you: by placing roadblocks before clifs so that you don't fell off, and not in the middle of the road. > What sucks is that I agree with much of what you say regarding > flexibility syndrome. I'm grappling with SVG right now because there > are so many ways to accomplish what appears visually to be the same > thing. On the other hand I don't want to alienate all of the > [FSM|Prolog|WebObjects|...] developers who have a really good > understanding of what have been shown to be pretty reasonable models > of web development. Believe me, we share the exact same concern, but as I don't feel sorry for those programmers that dislike Cocoon just because it's written in Java, we can't possibly avoid taking some freedom-limiting decisions. At the same time, as others very well expressed, we must find the best way to do something, even if this requires changing our mind a little bit (and learn concepts like Scheme continuations). Keep in mind, though, that the result is always a meritocratic vote, thus a well balanced situation. > Unless of course what we come up with really is better on all axes, > in which case full steam ahead! That's exactly my point: we have generators/transformers/serializers. They are SAX-based components. This is a *big* limitation. Should we create a new strategy for pipelines for those who don't care about performance and what to use DOM? Here is an example where abstraction is FS, until somebody indicates a need for this. On the other hand, the Cocoon Environment is abstracted: but this is required to have an elegant way to have both CLI and servlet bahavior (and possibly, Avalon-component behavior). But, believe me, I tried so hard to avoid this because it imposed a big architectural design change. We couldn't find a better way and we abstracted it. Look at the discussion on the sitemap engine: if pluggable, people might add their own, but then we'll have different versions, possibly incompatible, different docs, different behaviors... is this freedom helping the users at the end or hurting them? I can go on forever. I finish with the last example, the one that made to think at Avalon: unlike C++, Java restricts multiple inheritance for classes. This is a pretty serious freedom limitation for programmers. But it forced me to think at a way to decomponse my components by projecting them into different multi-dimensional concern hyperplanes. (of course, having idendependently came up with this I didn't know the SoC terminology when I started, I was calling this "separation of contexts") Result: if Java had multiple inheritance, we wouldn't have Avalon, nor I would have understood the importance of SoC as a metric for system architectures (thus we wouldn't have Cocoon). Sure, it probably took decades of mistakes on multiple inheritance to lead the java inventors to the *big* decision to remove that feature. But that results in the best java feature being the *lack* of something. Clearly something that doesn't show off on the cover of a book, but it does tell you something about the dangers of FS. > Jason Foster > > P.S. How about using session URLs of the form... > > http://session:identifier@host/cocoon/webapp > > In a lot of browsers (but not all) if you follow one of these URLs > the browser remembers the credentials for the duration of the > session. Pretso! No URL rewriting, no cookies. Might have problems > with multiple windows though... Hmmm, surely worth investigating further.... thanks. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
