[RT] parallel pipeline streams

[Stefano Mazzocchi <st...@apache.org>]

Giacomo Pati wrote:
> 
> Willie Wheeler wrote:
> >
> > Hi all,
> >
> >         Also, I'd like to tackle the todo that says to pull the HTML out
> > of CocoonServlet, if somebody isn't already working on it.  I'm thinking
> > that it would be good to forward to a dynamically generated error page.
> > Is this what people have in mind?
> 
> Thank's for your offer to help.
> 
> I had the vision of something like an abstract, context neutral class
> that handles the error cases. Implementing concrete classes base upon it
> for the different contexts (mail, soap, html, ...) Cocoon might be
> working in. Maybe pluggable ErrorReporters?

Hmmmm, yeah, something like that.

I have the usual burst of RT about this. Here they come...

I picture four error levels divided into two stages

 1) adaptor       |
 2) engine        |---> startup
 3) component     | 

 4) pipeline      |---> operation

if the adaptor (servlet, command line) signal an error, it cannot use
any of the engine functionalities. In this case, it should use its own
error channel, for example

  servlet      -> servlet log
  mailet       -> mailet log  
  command line -> STDERR
  avalon block -> avalon logger

(note: there is no SOAP adaptor, SOAP is a protocol not a component
model, SOAP operation will be performed inside avalon, together with RMI
or CORBA these are different flavors of the same thing but we should not
care about "how" the cocoon execution is triggered but only "who" does)

Adaptor errors might be:

 - class not found
 - properties not found
 - container is not powerful enough
 - java version is too low
 - your memory is not enough
 - etc...

Now, when the adaptor sees that everything is good, it launches the
engine (org.apache.cocoon.Cocoon for C2). At this point, the engine
might generate errors:

 - configurations not found
 - sitemap not found
 - can't read directory
 - can't find class
 - xml not-well formed
 - etc...

I believe these should be sent back to the adaptor without any markup
formatting, the adaptor will know what to do with them.

The component layer will throw exception the engine will caught and
signal the adaptor.

NOTE: the adaptor could implement the ErrorHandler interface and it
could pass itself as an ErrorHandler interface to the engine.

So far for startup.

Now our engine is running and we are all well.

At runtime there are two modes of operation:

 1) operation data
 2) operation metadata

in 1) is where Cocoon works as expected
in 2) is where Cocoon generates data about the data previously generated
or contained inside

Case 2) is the infamous /Cocoon.xml page for C1, but also contains the
debug information you receive when something is wrong in your page, for
example, when the page is not well-formed or when the stylesheet cannot
be found.

Many people would like to incorporate this information nicely inside
their web site, removing Cocoon-specific graphics and having the chance
to filter out sensible information depending on who access the faulty
page.

More over, Cocoon should keep track of its own timings and provide this
information in a consumable form.

Again, I see two cases:

 a) runtime metadata
 b) runtime errors

For runtime metadata, there are no big problems. I picture
org.apache.cocoon.Cocoon implement Generator as well so that it can be
used to generate metadata about itself using whatever schema we decide
it's more convenient. Then it's up to you to place this into your
sitemap and manipulate it as you like... maybe creating png pictures of
the usage statistics, thru XSLT filtering and SVG serialization. Anyway
the above doesn't require any change in our model, it might also be
implemented as XSP or directly in code, this is up to who implements it.

For runtime errors, the situation is much more complex.

Runtime errors should be sent to the requestor, not to the underneath
error log. This is to avoid the hassle of having to open the log file
everytime something is wrong and understand which one was your log
(consider an environment where thousands of people are working on the
same cocoon at the same time!).

During pipeline operation there are two layers

 ------- data -------->
 ----- metadata ------>

data is what the client normally sees, we can call it "the surface
stream", metadata is what is generated "sideways" by the pipeline (for
example timing contents, pipeline tracing instructions, xslt messages,
etc), we can call it "the underground stream".

Cocoon1 merges the two pipelines using comments: the infamous "<!-- this
page was generated by Cocoon.... -->" comment is the only metadata
generated, but I believe it's pretty important both for  recognition (to
tell if the page was generated by cocoon) and performance tuning (as
well for cache operation).

How do we integrate the two pipelines?

For electronic signal handling, two channels can be merged using
orthogonal ways of propagation. But they are lucky (well, from this
point of view anyway), since they know they are using electromagnetic
waves only.

Here we are using _any_ possible binary format and there is only one
channel in an ordered octet stream. So, how do we do this?

First solution: discriminate for format

1) use the orthogonal channels were possible (comments, or XML
namespaces)
2) don't use them were this is not possible (general text, images, pdf,
etc...)

Second solution: discriminate for request

1) if the normal URI is called serialize the surface stream
2) if a special URI is called use the underground stream as a generator
for another pipeline.

This might require sitemap changes to incorporate the idea of parallel
streams.... well, food for thought.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------