cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2] (hopefully) last sitemap major changes
Date Tue, 04 Jul 2000 12:01:09 GMT
Niclas Hedhman wrote:
> 
> Giacomo Pati wrote:
> 
> > I see some cases where a serializer fires events to the trace stream before a
> > generator/transformer does (because of the semi parallel mechanism of the assembled
sitemap
> > components). Does this gives us any problems (I personaly do not know because I've
not made many
> > thought about that trace/error streams)?
> 
> Yes there will be very tricky 'sequencing' design problems.
> 
> The most interesting one;
> The SAX model allows for the document to 'fly-through' the whole processing chain, and
output
> generated before the whole of the input has entered the system. One would then, in the
Http case,
> feeding the return stream with the result. If now, an error condition is raised, such
as an
> exception, the Http stream can not be reset(), but must be completed.
> On top of this, we have complex SAX Consumers, such as Xalan, which may or may not buffer
N events
> prior to bursting out M events to the next SAX Consumer.
> What I am saying is, that a call to the TraceHandler on the line after the call to the
> ContentHandler, could be delayed into the TraceHandler by any number of other calls to
the
> TraceHandler.
> This would lead to an trace output that bears little ressemblance with what a human can
possibly
> decode in any lengthier document and less than trivial sitemaps. One could argue that
it would be
> possible to create a tool that can decode the trace and visualize it into something understandable,
> and I will honorably acknowledge such an attempt.
> 
> While thinking about it at this particular moment, one probably need to 'encapsulate'
a traced
> segment of code, such as
> th.startTrace(...)
> ch.startElement(....);
> th.endTrace(...);
> 
> with ... is all the location stuff.
> This look rediculously weird coding (assuming that most 'encapsulations' will be a single
statement,
> but behind the ch.startElement() could be thousands or more other SAX events.
> The tracer could then generate hierarchy, which both humans (although I don't think people
have any
> chances at this) and tools might easier understand.
> 
> But again tracing is a very desirable but complex subject, and I don't claim I have any
good
> solutions at hand.
> 
> And my angle is that the trace is generated in parallel with the Content, and not at
a later point
> in time.

I don't picture tracing to be the "clone" of every SAX event that is
generated inside the pipe.

This would not be only totally unreadable, but nothing really useful.

Tracing, at least to me, is something like

 <trace>
  <pipe view="default">
   <generator name="parser"/>
   <filter name="xinclude"/>
   <filter name="xslt"/>
   <serializer name="html">
    <mime-type>text/html</mime-type>
    <encoding>UTF-8</encoding>
   </serializer>
  </pipe>
  <cache>
   <status>missed</status>
  </cache>
  <time scale="millis">389</time>
 </trace>

or any information you require to "debug" your pipeline but that doesn't
give enough information to require being protected from the external to
give untrusted users too much information on the system.

This is my vision of tracing.

-- 
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 ---------------------



Mime
View raw message