>> An (IMHO) equally valid "theory" is that we could also make the >> semantics >> pluggable. > > I disagree here since looks like FS from all the point I look at it.
<grumble/> You're right, but... > Well, your statement could easily be extended to say that one > concept is > a Turing machine, everything else is implementation. > > And you'd be totally right even in this case. > > But as I wouldn't want to implement my webapps in assembly, I don't > think that this level of generality is going to be of any help for the > project or the users. Fair enough. By the same token though, I am skeptical that you believe that all programming should be done using the imperative model. I'm all for abstraction, but am leery of a single conceptual framework in which I must maneuver. <snip/> >> I can't wait to see how the "implicit" >> approach to defining a webapp works (Prolog! Prolog!), but I >> would also >> like to make sure that we have a common vision of what webapps, flow, >> resources, etc. actually are and what we're trying to accomplish. > > Ok, good point. I'll post a summary real soon. Thanks! <snip/> > 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!?). <snip/> > 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. BTW, it was a *really cool* approach to caching. 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. 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. Unless of course what we come up with really is better on all axes, in which case full steam ahead! 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... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
