cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
Date Sat, 18 Aug 2001 13:57:22 GMT
On Tue, 14 Aug 2001, Berin Loritsch wrote:

> Sylvain Wallez wrote:
> >
> > Berin Loritsch wrote:
> > >
> > > I have been giving _alot_ of thought about actions, components,
> > > and contracts in Cocoon.  Please pay attention to the different contracts
> > > in affect for the core components (tune in below for some comments):
> >
> > Great analysis !
>
> Thank you.  I've been with this for a while, so these represent most of our
> current understanding.
>
> > > 1) Action:  An action performs server side logic with _no_ display or
> > >    XML generation facilities.  It must be compatible with Thread Safety
> > >    constraints so that the majority of Actions can be ThreadSafe.
> > >
> > > 2) Generator: A generator performs XML generation from some external source,
> > >    whether it is a stream, an object, or database.  It must send SAX events
> > >    to the next component in a chain.  A Generator is always the first component
> > >    in a chain.  Due to the SAX implementation, it cannot be ThreadSafe--but
> > >    can be Pooled.
> > >
> > > 3) Transformer: A transformer recieves XML from a chain, performs some sort
> > >    of processing on the stream, and forwards the results to the next item in
> > >    a chain.  A transformer has the same issues regarding the SAX implementation,
> > >    and therefore has the same constraints.
> > >
> > > 4) Serializer: A serializer receives XML from a chain, and converts it to
> > >    an external stream.  A Serializer is the last element in a stream.  Again,
> > >    it has the same constraints placed upon it as Generator due to the same
> > >    issues.
> > >
> > > 5) Reader: A reader pulls an arbitrary resource from any source (much like
a
> > >    Generator), but it serializes a copy to an outputstream immediately.
> > >
> > > 6) Matcher: A matcher tests the URI for specific patterns, and is used to
> > >    select specific pipelines based on requests.  A matcher _must_ be ThreadSafe,
> > >    and provide only simple or quick processing.
> >
> > Why _must_ ? Even if matchers are likely to be more simple than actions,
> > the same analysis as the one you make for Action below (don't enforce
> > LifeStyle on work interfaces) can also apply to Matcher.
>
> Not quite.  The Matchers and Selectors have a contract with the Sitemap itself that
> is very strong.  The Sitemap assumes that everything in its _direct_ control (which
> does not include the pipeline components) is ThreadSafe.  This is the way the Sitemap
> is written.  *ESPECIALLY* the factory matchers and selectors.  These have absolutely
> no margin for anything but a thread safe implementation because they are embedded
> directly in the code.

This is the right analysis I was looking for but couldn't name it! Thank
you Berin.

Giacomo


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


Mime
View raw message