cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Foster <>
Subject Re: initial checkin of the Scheme code
Date Tue, 11 Dec 2001 19:13:53 GMT
>> 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.


>>  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.



> 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!?).


> 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 

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...


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:
For additional commands, email:

View raw message