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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
