----- Original Message -----
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 11, 2001 8:19 PM
Subject: Re: [RT] Managing Flow and Resources
> Nicola Ken Barozzi wrote:
> >
> > ----- Original Message -----
> > From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, December 11, 2001 3:03 PM
> > Subject: Re: [RT] Managing Flow and Resources
> >
> > <snip/>
> >
> > > I think you are oversimplifying: I agree with you that actions and
> > > action-sets are something that should not be in the sitemap (I always
> > > found strident the different degree of reuse you had with pipeline
> > > components and actions), but at the same time, the current sitemap
> > > semantics is IMO very well designed for stateless publishing needs,
> > > which still are the great majority of the web resources.
> >
> > IMO Actions are needed in the pipeline.
> > Sometimes you want to apply actions to a whole "class" of pipelines,
> > not only to the current flowing "instances".
>
> When I say SoC between 'sitemap' and 'flowmap', I don't necessarely mean
> that you have to call a flowmap from a sitemap and stop there.
>
> In fact, it could be possible, to 'mount' a sub-sitemap to a flowmap.
>
> In this case, you could 'wrap' your sub-sitemap with some
> flow-describing code that, for example, might manage access rights,
> authentication or stuff like that.
>
> Once we have separated the concerns, it's up to you to 'compose' them in
> the best way and I think that if sitemaps can mount flowmaps and
> flowmaps can mount sitemaps, the balance is achieved and actions can be
> removed from the sitemap.
coooool :-)
> > For example, for access control or single routine db actions they
> > are good.
> > The problem arises when the interaction is more complex than
> > a simple request-response.
> > Sessions take care of the data part, flowmaps or such should
> > take care of the flow part.
>
> No, I picture sitemaps defining stateless activity and flowmaps stateful
> activity.
Ehm, yes, i agree.
I was saying that -now- the data used between interactions
is defined in the session, but it's not enough.
Flowmaps are needed to complete the
picture and define also the flow, which is not just the snapshot
of states but the definition of the sequence.
Anyway, I agree.
> I know it's a rather unusual way of thinking at web programming, but I
> have the feeling there is incredible usefulness in this approach, since
> change or reusing those *maps increase substantially the more separate
> their concerns are kept.
I tend to see sitemap resources as what you define here as sitemaps,
and the pipelines with actions as flowmaps.
Could it be that the concept has always been there but was
misunderstood? ;-)
> [NOTE: Access control *is* a stateful activity, almost by definition:
> browsers keep on sending the user/password pair to keep the state]
...not for the server.
You could type in the password at every request or have it resent
by the browser, it's just irrelevant to the server.
The server can cache the authentication result it made the first time,
but it could also check the database every time.
For me stateful means basically "Session".
The rest is stateless.
Browsers do not keep sending user/password to keep the state,
there's the session id for that.
Maybe I'm missing the point.
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<[EMAIL PROTECTED]> Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
