cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Date Fri, 28 Jun 2002 15:03:14 GMT
Stefano Mazzocchi wrote:

>Carsten Ziegeler wrote:
>>And here are the results of the Cocoonian jury (so far):
>>        Carsten John Stephan Piroumian Vadim Sylvain Berin  Stefano
>>a) -1                                          X
>>   -0
>>    0     X                                            X
>>   +0                   X                X
>>   +1             X             X
>>b) -1
>>   -0                                          X
>>    0
>>   +0             X             X        X
>>   +1     X             X                              X      X
>>c) -1                                                  X
>>   -0
>>    0
>>   +0     X       X     X       X
>>   +1                                    X     X
>>d) -1     X       X     X                X             X
>>   -0                           X
>>    0
>>   +0                                          X
>>   +1
>>Ok, we have enough -1 on d) so we can skip this solution.
>>We have two +1 on a), but a -1 from Sylvain
>>We have four +1 on b) and no -1
>>We have two +1 on c) and a -1 from Berin
>>So it seems that we are prefering to remove the SAXConnectors ( a) or b) )
>>over redesigning the concept ( c) ).
>>As we have four +1 on b) and no -1, b) is the way to go.
>>Everyone agreeing with this?
>I do, but I think we need to hear why Sylvain wants to keep it.

First of all, an answer to Nicola Ken's request for explanation of the 
-1 : this -1 was for "deprecation and then removal", and explained in 
the -0 for (b) : if the vote finally decides to remove SAXConnector, 
then remove it now. There are enough changes in 2.1 to allow direct 
removal without a preliminary deprecation phase, and it will be harder 
to remove them in 2.1.x if they're present - even if deprecated - in 2.1.0.

Now why I wans't in favor of removing it : although I never used it (as 
most of us), the proposal for their removal  has reminded me of their 
existence and popped some RTs in my bubbling head ;)

A common problem with Cocoon is that when everything goes well, it's a 
real pleasure, but when things go bad, it's very difficult to know why 
they go bad : you have some kilometer-long cryptic stacktraces on 
screen, the generator reports an error when a transformer fails (because 
of the pipelining), the logs are difficult to search, etc, etc.

So came to my mind some possible uses of SAXConnector to solve this and 
help error reporting.

The first one I thought of was a connector verifying well-formedness of 
the SAX stream, which could be usefull for debugging generators and 
transformers. This may not be of primary interest since few users write 
such components, and experience has also shown that balancing the tags 
isn't the most difficult thing in transformers (state preservation is 
the difficult point).

The second one is far more interesting : when an error occurs in e.g. a 
transformer, the exception travels up the processing chaing up to the 
pipeline, and it is very difficult at that point to know which element 
of the pipeline caused the error. What would be good is to show the user 
a message saying "Error in transformer 'xslt' at sitemap.xmap:342", 
followed by the actual exception raised by the transformer.

This kind of message is possible if we insert between each component of 
the pipeline a connector that traps any exception and reports it along 
with the location in the sitemap. I recently suggested to add location 
information to methods of Pipeline, which would allow to achieve the 
desired behaviour.

Now why a SAXConnector and not a particular pipeline implementation ? If 
we look at the use cases for connectors up to now (including the current 
ProfilingConnector), they're all mainly targeted at debugging/tuning and 
are thus orthogonal to the application itself. Changing the pipeline 
changes the application behaviour (component usage is different with and 
without caching), while connectors are just "probes" inserted between 
the elements of the pipeline, and don't change the application behaviour.

But SAXConnector isn't so orthogonal to Pipeline as it should be : for 
the profiler, we need to have a NonCachingProfilingPipeline and a 
CachingProfilingPipeline to properly set up things. This means we must 
combine each connector with each pipeline implementation, which IMO 
reveals a flaw in the design : the connector not only "connects", but 
must also be notified of the start and end of the pipeline construction. 
What we need is more a connection handler used by the pipeline to 
connect its components than a simple factory of unrelated connectors as 
we have today.

So finally, I'm in favor of removing SAXConnector _now_, but be prepared 
to see something appear in the future that will be really orthogonal to 
pipelines and will hopefully improve the so-called "user experience" 
when an error occurs !


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message