>> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|