Jason Foster wrote:
>
> > Moreover, now that we clearly identified the SoC between
> > syntax/semantics and many examples showed that the same semantics could
> > be equally expressed with different syntaxes, it's good that we now
> > concentrate on the semantics and let the syntax be the last of our
> > concerns.
> >
> > In theory, if one likes, we could make the syntax wrapper pluggable, so
> > that you could write your flow-driving code with the syntax you like the
> > most (or it best fits your favorite IDE)
>
> 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.
> A little while back I sent in a message that tried to raise the issue of
> what aspects of Cocoon should be rigidly specified and what aspects should
> be open. So far there have been no replies, but I'd like to re-raise the
> issue anyways.
Yes, I forgot to reply to that, I'll do it now.
> As things stand Cocoon appears to define the following conceptual
> invariants:
>
> - Requests and Responses
> - Pipelines
> - Generators
> - Transformers
> - Serializers
>
> The sitemap (which I consider separate from the core aspects of Cocoon, but
Ok, totally. I agree with you.
> please don't hold that against me) also defines at least one other concept:
>
> - Views
>
> Everything else is implementation ;)
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.
> The current discussion of flows and resources is important (and fun!) but
> it seems to be moving very quickly towards implementation without having
> resolved some key conceptual issues.
Hmmm, I don't resonate with this view of the problem.
> 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.
> For example a webapp could be seen as:
>
> - a "standard" event-driven, object-oriented application where web requests
> are translated to method invocations (WebObjects)
> - a continuation-based application where the choice of continuation is
> based on a request parameter
> - a FSM
> - a set of web pages hooked together manually by a developer who manages
> session and persistance aspects manually
> - a test for provability given axioms and theorems
>
> Should Cocoon provide a formal definition of a webapp? Personally I don't
> think so. My (not terribly well informed) opinion is that Cocoon should
> add one more concept, the "Controller", which is an implementation of the
> GoF strategy pattern, and that is responsible for controlling the response
> to requests. Different controllers would embody different models of
> webapps.
My FS alarms are still ringing.
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.
For the same reason, I'd rather investigate which one of these
strategies fits best with the SoC concepts we based Cocoon on and
concentrate on that.
If (and only *if*) people will ask for a different strategy, we'll
consider to implement a pluggable system, but, for now, I consider this
elegant only on paper, but very dangerous for both the project and the
community because it would spread the usage over different strategies
instead of evolving one into the best.
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.
--
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]
