cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <geoff.how...@gmail.com>
Subject Re: [RT] A Groovy Kind of Sitemap
Date Thu, 29 Jul 2004 23:07:16 GMT
I'm still in skimming mode, but I'll lob a nearly incoherent thought
in from the sidelines...

On Thu, 29 Jul 2004 10:34:29 -0700, Stefano Mazzocchi
<stefano@apache.org> wrote:

...

> A little bit of history is needed:
> 
> - at the beginning there was no sitemap. all the pipeline machinery was
> "embedded" into documents using processing instructions. when it was
> proposed to move on, nobody ever objected.
> 
> - cocoon was still a publishing framework. this means it was meant to
> respond to "GET" requests. Pier and I sat down in his office in Erba
> (CO) in Italy and created the first draft of the sitemap. This was 4
> years ago. Given the high declarativity of the sitemap and given the
> impressive mind-bending nature of declarative languages that we had
> experienced for the first time a few years earlier with XSLT, the use of
> XSLT as a guiding path (and Pier's previous experience at IBM with
> StyleBook) was a no brainer. We *never* thought about a different syntax.
> 
> - the sitemap has not changed since then, if only a few things, mostly
> actions, and I was against them, but I saw the need and had no better
> idea (and no time at that time to spend more on it).
> 
> - actions soon showed weaknesses because the degree of reusability of
> actions is *much* lower than that of any other kind of sitemap
> component, showing that they are misplaced.
> 
> - the need to separate "resource production" from "flow control" can be
> seen as an extension of MVC where the view is a pipeline, the controller
> is a mix of flow control, business logic and glue between the two and
> the model is whatever you use to pass data from the two.
> 
> At this point, I went to Giacomo's in Zurich to talk about the
> "flowmap", as we called it at that time. We were so much ingrained into
> finite state machines that we didn't even think about the ability to
> "freeze the execution state" (which is what continuations are all about).
> 
> The flowmap, written in XML, was written on a few whiteboards, but it
> was so ugly that it was never even written into an RT.
> 
> It was Ovidiu that came with that idea and radically changed my way of
> thinking about this "flowmap", which soon became "flowscript".

I'm going to try to express a nagging feeling I don't like about the
current system of flow+sitemap:  It feels weird jumping from place to
place.  Requests come into the sitemap, have the matching/sitemap
rules applied, then possibly go out to flowscript, then back into the
sitemap - matched again, then processed.  So we have,
1) request matching (sitemap)
-----
2) backend business logic (flowscript, flowscript-calling-java)
3) complex pipeline selection (flowscript, sendPage)
4) page flow control (flowscript, continuations)
-----
5) pipeline construction/composition (sitemap)

At a gut level, something feels awkward about all that - not in any of
the individual pieces but more in how they stitch together/work
together.  I feel like I'd rather have the top section (item 1) and
the last one (item 5) not be the "same" (this is not a "symetry
argument by the way).  Obviously I'm implying some mixing of concerns
is happening, but I'm not sure I see where they are.

Maybe it's just that I'd rather that the uris used to go back to the
sitemap be simple named pipeline definitions with no new
matching/selection functions or no ability to go back into flow. 
Clearly delineated somehow as an endpoint, not room for further
decision branching.

Or maybe the problem is between the first two sections: I have to go
into the sitemap to get into flow, then go back to the sitemap
(somewhere else).  Maybe if some/all uris began being evaluated by
flow, which selected the pipeline, which then couldn't send back into
flow.

Maybe it's only that there is no distinction between the different
"pipeline" definitions in the sitemap, some are end-points, some are
entry-points and some are both.  Sort of a "map:receive" section, and
a "map:process" section, with slightly different rules betweent them.

Why insert this stream of consiousness into this discussion?  I have a
gut feeling that something in this discussion could lead to a solution
along these or totally new lines that cures this "uneasiness", or
could make it even worse.

...

>                                  - o -
> 
> Instead of arguing about the status quo, let's give Ugo the space he
> needs to show us where we can innovate.

Of course.

> If Cocoon is what it is today, it's not because we remained where we
> were, but because we allowed people to innovate internally and with an
> open and friendly attitude and we "guided" our user base in new
> directions and never failed to provide them a better environment then
> before.
> 
> Let's NOT forget that.

Sounds good.
Geoff

Mime
View raw message