Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Tue, 11 Dec 2001 07:19:47 -0500
Subject: Re: initial checkin of the Scheme code
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: Jason Foster <jafoster@uwaterloo.ca>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3C154C8C.116BD387@apache.org>
Message-Id: <5E0F7F26-EE31-11D5-B147-000A27E14D02@uwaterloo.ca>

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

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.

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 
please don't hold that against me) also defines at least one other concept:

- Views

Everything else is implementation ;)

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

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.

Comments?  I don't think I'm out to lunch, but you never know...

Jason


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org