Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <395B2C04.58470D2B@apache.org>
Date: Thu, 29 Jun 2000 12:59:16 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] resource views, error handling, pipeline debugging
References: <395A0DA1.46AD91B4@apache.org> <395AE5BF.CC2DD737@localbar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Niclas Hedhman wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > Pipeline revised
> > ----------------
> >
> > I recently came to the conclusion our pipe model must be enhanced. The
> > pipe currently passes SAX events. These are data events.
> >
> > I want to add a metaevents pipeline, sort of a logging/tracing pipeline
> > where the components throw everything that is related to event
> > generation and not event payload.
> >
> > Example of this are:
> >
> > - pipeline tracing (knowing what's going on, XSLT messages, FOP page
> > generation output, pipeline timings, etc...)
> >
> > - error reporting (xml non-wellformed, exception inside a component,
> > exception inside a server page)
> >
> > So, every component is given access to the stream of events of the next
> > component, plus the orthogonal stream of pipeline metaevents. The
> > implementation of this metaevent stream is not semantic abstract like
> > SAX but its semantic specific (like any logging class).
> >
> > Something like
> >
> >   public interface PipelineLogger extends Generator {
> >      public void startPipeline();
> >      public void endPipeline();
> >      public void trace(Component origin, String message);
> >      public void error(Component origin, String message, Exception e);
> >      ...
> >   }
> >
> > This doesn't change the shape of the pipeline, but since PipelineLogger
> > extends Generator, it is possible to use the "tracing" results of a
> > pipeline, XML-ize them and feed them thru another pipeline for
> > presentation.
> >
> > This solves the issue of error handling with multiple user agents. The
> > pipeline as a whole becomes a generator for another pipeline.
> 
> THANK YOU!!!
> I knew it would come to you sooner or later...

Hey, how unfair, I'm not that slow... :)
 
> It is easy to see/define how a stream is split, but the hard part is how is
> it joined back?
> And even worse, how is this detailed in the Sitemap??

:-? Sorry, I don't understand you here.

> Tough questions indeed, and I will twist my head some, and see what comes
> about later today.

ok
 
> > Resource views
> > --------------
> >
> > Well, with a particular request parameter
> >
> >  http://myhost/myURI/resource?cocoon:view="xxx"
> >
> > where all "cocoon:*" names are reserved for future use. It's an XML-ish
> > hack. but it works and it's easy to parse and easy to read and easy to
> > edit by hand.
> 
> Not good to use "cocoon:". I have tried to use : in parameters before, and
> you end up with a lot of misunderstanding in many browsers and URL
> decoders. For it to work you then have to put in "cocoon%3A" which looks
> "bad".

Damn. Any suggestion?
 
> > So, for example a pipeline like
> >
> >  g -> f1 -> f2 -> f3 -> s
> >
> > can be refactored as
> >
> >   [ g ] [ f1 , f2 , f3 , s ]
> >   [ g , f1 ] [ f2 , f3 , s ]
> >   [ g , f1 , f2 ] [ f3 , s ]
> >   [ g , f1 , f2 , f3 ] [ s ]
> >
> > Sort of pipeline diagonalization.
> >
> > Why this? well, mainly to reduce verbosity, the components of a view
> > might change, but the component of a viewer might not.
> 
> And sorry for being an idiot,

You're no idiot.
 
> If I have a resource;
> /abc/def/ghi
> and you say that it can be viewed in many ways, how is that different from
> 'extending' the resource itself;
> /abc/def/ghi/complex-semantic
> (other than syntactically in the URI)

Hu, great point, didn't think of this one... see below...
 
> And if so, could not all you are trying to accomplish, already be done by
> matchers?
> <map:match pattern="*/complex-semantic">
> 
> whereby the $1 is passed into the Generator.

Yes, yes, you are totally right. The "view" element is completely
redundant, it doesn't add functionality you didn't have with
matchers.... but it gives you a way to focus more on it.

Call it syntax sugar. Call it "Stefano would like you to see resources
as multidimensional objects with different views as orthogonal
projections".

In fact, both filters and generators are "xml producers" but we
introduced the notion of them to simplify and crystalize a vision of
them.

I'm trying to do the same with these views.
 
> I must be missing something big here, since I don't think you have
> overlooked this.

No, of course not. I wanted this to remain the very last thing to define
exactly because its redundant... i wanted to see if it was necessary.

Let us suppose it's not.

How would you generate your site for off-line viewing? Cocoon offline
mode requires you to give it xlinking information in order to be able to
browse the site. And all URIs must follow a very specific pattern,
something like (this is pseudosyntax, just as an example)

 <match uri="a/b">
  ...
 </match>
 
 <match uri="a/b/off-line">
  ... 
 </match>

and you must do this for all of your matchers since rarely the xlinked
view and the normal view are the same and require the same pipeline to
be generated.

So, by creating the "view" notion and the view/viewer elements, I wanted
to be able to reduce verbosity by introducing recurring concepts, also
avoiding errors due to wrong use of URI spaces.

<view> defines a contract between users and URI spaces.

Best solution would be to introduce the "view" notion in HTTP (sort of
what WebDAV does), but it would require you to write a special client to
browse the pages.

So we have to "hardcode it" into the URI.

Say you have 

 http://host/path/resource

and you want to access its "tracing" view to find out how much it took
to generate it or what did the XSLT stylesheet tell you.

The HTTP request is

 GET HTTP/1.0 /path/resource

the best solution would be

 GET HTTP/1.2 tracing /path/resource

but the mountain is _way_ too hard to climb in that direction.

So, given HTTP, we have to modify the URI. A URI is composed by

 http://host:port/path/resource?query

Let's try to modify all of them:

 1) host 
  
     www.myhost.org -> normal view
     tracing.myhost.org -> tracing view

  2) port

     host:80 -> normal view
     host:10000 -> tracing view

  3) resource (what Niclas proposes)

     path/resource -> normal view
     path/resource/tracing -> tracing view

  4) query (what I proposed)

     path/resource -> normal view
     path/resource?cocoon-view="tracing" -> tracing view

the first 2 are not directly controllable by Cocoon.

So the choice is between 3 and 4.

Admittedly, 3 has some advantages since it's independent on the HTTP
action and can be safely included in links, but also disadvantages since
it could create naming conflicts.

Hmmm, I would like to know your comments on this before stating my vote.

>(Stefano is not Mohammed - Why go to the mountain, when
> you can turn it... :o)

I know somebody would have said that, I just wanted to see who was the
first one :)

I guess the mountain twisting idea shows my egocentricy, doesn't it? :)

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