You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/06/27 12:16:26 UTC
[VOTE]: The future of the SAXConnector
Hi,
I refactored the profiling code a little bit, now the
SAXConnectors are not used anymore for profiling, making
the use of profiling a little bit easier.
But I think we should now vote for the future of SAXConnectors
as we already have the (incompatible) changes with the
handling of event and stream pipelines; so another one in
this area doesn't hurt.
So, here we go:
a) Deprecate the SAXConnectors and remove it asap.
b) Remove it now
c) Change the concept, so that it is possible to configure
the used SAXConnector on a map:pipeline base.
d) Leave it as it is
I'm +1 on b) and -1 on d).
c) seems to be FS, but if there is a real need for SAXConnectors
we should go for c), so this is a +0 on c).
PS: I like clear votes...
Please make your votes.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE]: The future of the SAXConnector
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>>> From: Stephan Michels [mailto:stephan@apache.org]
>>>
>>> On Thu, 27 Jun 2002, John Morrison wrote:
>>>
>>>
>>>
>>>>> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>>>
>>>>> Hi,
>>>>>
>>>>> I refactored the profiling code a little bit, now the
>>>>> SAXConnectors are not used anymore for profiling, making
>>>>> the use of profiling a little bit easier.
>>>>>
>>>>> But I think we should now vote for the future of SAXConnectors
>>>>> as we already have the (incompatible) changes with the
>>>>> handling of event and stream pipelines; so another one in
>>>>> this area doesn't hurt.
>>>>>
>>>>> So, here we go:
>>>>>
>>>>> a) Deprecate the SAXConnectors and remove it asap.
>>>>>
>>>>
>>>> +1
>>>>
>>>
>>> +0
>>>
>>
>>
>> +0
>>
>>
>
> -1
Since a -1 *must* be accompanied with a compelling technical
explanation, and since you seem to be the only one against this
proposal, could you please add it?
Thanks.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE]: The future of the SAXConnector
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> > >>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > >>>>
> > >>>>Hi,
> > >>>>
> > >>>>I refactored the profiling code a little bit, now the
> > SAXConnectors
> > >>>>are not used anymore for profiling, making the use of profiling a
> > >>>>little bit easier.
> > >>>>
> > >>>>But I think we should now vote for the future of
> > SAXConnectors as we
> > >>>>already have the (incompatible) changes with the handling
> > of event
> > >>>>and stream pipelines; so another one in this area doesn't hurt.
> > >>>>
> > >>>>So, here we go:
> > >>>>
> > >>>>b) Remove it now
>
> +1 SIMPLIFY!
>
> > >>>>c) Change the concept, so that it is possible to configure
> > >>>> the used SAXConnector on a map:pipeline base.
>
> -1 Cocoon already has too much going on behind the scenes. The
> concept of SAXConnectors is dubious at best. Their functions
> can easily be performed as Transformers, so they only serve
> to slow things down without providing a compelling reason for
> existing.
>
> > >>>>d) Leave it as it is
>
> -1 Kill it!
I agree, overcomponentization is just another pitfall that leads to FS.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE]: The future of the SAXConnector
Posted by Berin Loritsch <bl...@apache.org>.
> >>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >>>>
> >>>>Hi,
> >>>>
> >>>>I refactored the profiling code a little bit, now the
> SAXConnectors
> >>>>are not used anymore for profiling, making the use of profiling a
> >>>>little bit easier.
> >>>>
> >>>>But I think we should now vote for the future of
> SAXConnectors as we
> >>>>already have the (incompatible) changes with the handling
> of event
> >>>>and stream pipelines; so another one in this area doesn't hurt.
> >>>>
> >>>>So, here we go:
> >>>>
> >>>>b) Remove it now
+1 SIMPLIFY!
> >>>>c) Change the concept, so that it is possible to configure
> >>>> the used SAXConnector on a map:pipeline base.
-1 Cocoon already has too much going on behind the scenes. The
concept of SAXConnectors is dubious at best. Their functions
can easily be performed as Transformers, so they only serve
to slow things down without providing a compelling reason for
existing.
> >>>>d) Leave it as it is
-1 Kill it!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE]: The future of the SAXConnector
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Stephan Michels [mailto:stephan@apache.org]
>>
>>On Thu, 27 Jun 2002, John Morrison wrote:
>>
>>
>>
>>>>From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>>>>
>>>>Hi,
>>>>
>>>>I refactored the profiling code a little bit, now the
>>>>SAXConnectors are not used anymore for profiling, making
>>>>the use of profiling a little bit easier.
>>>>
>>>>But I think we should now vote for the future of SAXConnectors
>>>>as we already have the (incompatible) changes with the
>>>>handling of event and stream pipelines; so another one in
>>>>this area doesn't hurt.
>>>>
>>>>So, here we go:
>>>>
>>>>a) Deprecate the SAXConnectors and remove it asap.
>>>>
>>>>
>>>+1
>>>
>>>
>>+0
>>
>>
>
>+0
>
>
-1
>>>>b) Remove it now
>>>>
>>>>
>>>+0
>>>
>>>
>>+1
>>
>>
>
>+0
>
>
-0 (means : _if_ it should be removed, remove it now)
>>>>c) Change the concept, so that it is possible to configure
>>>> the used SAXConnector on a map:pipeline base.
>>>>
>>>>
>>>+0
>>>
>>>
>>+0
>>
>>
>
>+1
>
+1 : per-pipeline configuration is better that a global one
>>>>d) Leave it as it is
>>>>
>>>>
>>>-1
>>>
>>>
>>-1
>>
>>
>
>-1
>
+0.5
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE]: The future of the SAXConnector
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stephan Michels [mailto:stephan@apache.org]
>
> On Thu, 27 Jun 2002, John Morrison wrote:
>
> > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > >
> > > Hi,
> > >
> > > I refactored the profiling code a little bit, now the
> > > SAXConnectors are not used anymore for profiling, making
> > > the use of profiling a little bit easier.
> > >
> > > But I think we should now vote for the future of SAXConnectors
> > > as we already have the (incompatible) changes with the
> > > handling of event and stream pipelines; so another one in
> > > this area doesn't hurt.
> > >
> > > So, here we go:
> > >
> > > a) Deprecate the SAXConnectors and remove it asap.
> > +1
>
> +0
+0
> > > b) Remove it now
> > +0
>
> +1
+0
> > > c) Change the concept, so that it is possible to configure
> > > the used SAXConnector on a map:pipeline base.
> > +0
>
> +0
+1
> > > d) Leave it as it is
> > -1
>
> -1
-1
Vadim
> > > I'm +1 on b) and -1 on d).
> > >
> > > c) seems to be FS, but if there is a real need for SAXConnectors
> > > we should go for c), so this is a +0 on c).
> >
> > I've not needed it and if I do I'll use the new so +0.
> >
> > > PS: I like clear votes...
> >
> > :)
> >
> > J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE]: The future of the SAXConnector
Posted by Stephan Michels <st...@apache.org>.
On Thu, 27 Jun 2002, John Morrison wrote:
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> > Hi,
> >
> > I refactored the profiling code a little bit, now the
> > SAXConnectors are not used anymore for profiling, making
> > the use of profiling a little bit easier.
> >
> > But I think we should now vote for the future of SAXConnectors
> > as we already have the (incompatible) changes with the
> > handling of event and stream pipelines; so another one in
> > this area doesn't hurt.
> >
> > So, here we go:
> >
> > a) Deprecate the SAXConnectors and remove it asap.
> +1
+0
> > b) Remove it now
> +0
+1
> > c) Change the concept, so that it is possible to configure
> > the used SAXConnector on a map:pipeline base.
> +0
+0
> > d) Leave it as it is
> -1
-1
>
> > I'm +1 on b) and -1 on d).
> >
> > c) seems to be FS, but if there is a real need for SAXConnectors
> > we should go for c), so this is a +0 on c).
>
> I've not needed it and if I do I'll use the new so +0.
>
> > PS: I like clear votes...
>
> :)
>
> J.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE]: The future of the SAXConnector
Posted by John Morrison <jo...@ntlworld.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> Hi,
>
> I refactored the profiling code a little bit, now the
> SAXConnectors are not used anymore for profiling, making
> the use of profiling a little bit easier.
>
> But I think we should now vote for the future of SAXConnectors
> as we already have the (incompatible) changes with the
> handling of event and stream pipelines; so another one in
> this area doesn't hurt.
>
> So, here we go:
>
> a) Deprecate the SAXConnectors and remove it asap.
+1
> b) Remove it now
+0
> c) Change the concept, so that it is possible to configure
> the used SAXConnector on a map:pipeline base.
+0
> d) Leave it as it is
-1
> I'm +1 on b) and -1 on d).
>
> c) seems to be FS, but if there is a real need for SAXConnectors
> we should go for c), so this is a +0 on c).
I've not needed it and if I do I'll use the new so +0.
> PS: I like clear votes...
:)
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Short class names in .xconf (was :Re: SAXConnector use cases (was...))
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>
>>Stefano Mazzocchi wrote:
>>
>>>Sylvain Wallez wrote:
>>>
<snip/>
>>Yes. I also think there are many components that actually aren't. If we
>>consider some of the subpackages of org.apache.cocoon.components such as
>>browser, deli, hsqldb, we can say they aren't component (a
>>component-like interface and a single implementation).
>>
>>So why have they been designed as components ? Because we want to be
>>able to choose to include them or not, and if yes, give them some
>>configuration. The usual way for this is to define a component and
>>configure it in cocoon.xconf, leading to over-componentization. But what
>>other way do we have ?
>>
>>
>
>What other way? What about the good old "new Object()"?
>
>
Sure, I (still) now this way ;)
But I was saying that Avalon itself encourages overcomponentization
since it makes it so easy to manage an object's lifecycle. On a
"regular" object, you have to manage yourself creation, configuration
(by passing a child configuration of an enclosed component ?), etc.
Since we're all lazy, we just ask Avalon to do that, even if not really
required.
<snip/>
>>There's an interesting feature in Avalon role management that is IMO not
>>enough used : hints, which associate short names to full class names.
>>
>>
>
>Oh, no, I disagree. 'hints' are re-inverting the control and many on
>avalon-dev suggest that cocoon should not have been using Avalon for
>those cases where it already needed what classes to instantiate.
>
>
I don't have the time to follow avalon-dev (although I must find it
since important things are happening), but I can guess that this
re-inversion of control is when a component uses hints to lookup other
components.
What I suggest here doesn't relate to this problem, as it is to use
hints as "class short names" in the configuration files. This doesn't
re-invert anything since these short names aren't used in component
lookup, but only as a user-friendly way of writing the container
configuration.
>If avalon is used just as a simpler way to perform classname lookup,
>that's not exactly a difficult thing to do ourselves.
>
What do you mean ? Have the CocoonComponentManager handle these short
names ? This can be of general interest, so why not add this to Avalon ?
>>Their use is currently limited to ComponentSelectors, but they could
>>also be used in other configurations to avoid naming classes for builtin
>>implementations.
>>
>>
>
>No, let's stay away from hints as much as possible.
>
>
>
>>Look to the following xconf lines with the eyes of a cocoon newbie. The
>>first one is what we currently have with the fully qualified class name,
>>and the second one makes use of a hint for that class.
>>
>>1 : <pipeline
>>class="org.apache.cocoon.components.pipeline.CachingPipeline"/>
>>2 : <pipeline type="caching"/>
>>
>>What the average user wants is to choose between caching and
>>non-caching, i.e. the _feature_ and doesn't care about the actual class
>>name (which btw, makes cocoon.xconf unreadable and frightening)
>>
>>
>
>Agreed, totally. But the above is not something that avalon should be
>used for because avalon is not a framework for instatiating objects. As
>I said, you have java to do that.
>
Pipelines *are* components. What I propose here doesn't change*anything*
to Cocoon/Avalon's internals and is just a simplified notation that will
avoid users to manipulate these clumsy class names, and use short
feature-related names instead.
No re-inversion of control, no over-componentization. Just simple and
readable names.
You must also be aware that many Cocoon users consider it for its XML
processing abilities and aren't really interested in the underlying java
classes. This is a consequence of being a nice high-level framework.
Compared to that, the .xconf is really low-level with all these class
names around and really user unfriendly.
>>The second line would be easily possible if we added hints in
>>cocoon.roles for the implementations of each role built into cocoon.
>>This would allow a classname-less cocoon.xconf for standard uses, while
>>still allowing advanced users to plug in their own implementations by
>>explicitely naming the class.
>>
>>
>
>Hmmm, I dunno, what do others think?
>
>
Yes, please share your opinions.
I personnaly think this may increase Cocoon's usability and reduce the
learning curve required for people to start modifying the .xconf.
<snip/>
>>>It would be enough to have a cocoon configuration trigger that says:
>>>
>>>- assemble pipelines for maximum performance (means no debug/trace
>>>overhead)
>>>- assemble pipelines for maximum information (means lots of debug/trace
>>>overhead)
>>>
>>And this is where hints come in handy. Imagine such a configuration :
>>
>><pipeline type="caching">
>> <connection type="profiling"/>
>></pipeline>
>>
>>We just name the wanted fonctionnality, and not the classes that
>>implement it. No "org.apache.cocoon.components.pipeline.CachingPipeline"
>>or "org.apache.cocoon.components.saxconnector.ProfilingSAXConnector".
>>Just "caching" and "profiling".
>>
>>
>
>Yes, something like this... but I'm skeptical about placing the more
>weakly typed indirection for class lookup. We should have more explicit
>configurations at the expense of a weaker extensibility but a higher
>coherence.
>
This doesn't reduce extensibility. As I said, we can provide short names
for components built into Cocoon, but the full class name notation is
still available for custom implementations.
>>>So the uses doesn't have to *know* how to do it, but the functionality
>>>you wanted is there without the need for overcomponentization which
>>>smells like FS too much.
>>>
>>>How does that sound?
>>>
>>My impression is that FS is smelling stronger when so many classes have
>>to be explicitely named by a user that just wants to process XML. A
>>broader use of hints would inject simplicity in the xconf without
>>sacrificing the flexibility that we need. Cocoon.xconf would then change
>>from a class-assembly description to what it really should be, a
>>readable and manageable configuration file.
>>
>>Note also that hints could equally be used in the <map:components> of
>>the sitemap. I already proposed this in
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101111373910829&w=2 but
>>it didn't had much acceptance at that time because the treeprocessor was
>>just born and this was incompatible with the compiled engine.
>>
>>
>
>I agree that classnames are verbose, but hints might become as verbose,
>or, if not, might lead to name collisions once we have blocks. So I'm
>not a big fan of hints at all.
>
>
Collisions aren't likely to happen as the scope of a hint (or short
name) is the role, and I don't really see what will be the problem with
blocks.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
Re: SAXConnector use cases (was Re: [VOTE]: The future of the
SAXConnector)
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>
> Stefano Mazzocchi wrote:
>
> >Sylvain Wallez wrote:
> >
> >
> >
> >>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 !
> >>
> >>
> >
> >I see your point and I agree, but I would like to add a little warning
> >to what you're trying to achieve.
> >
> >Cocoon suffers from overavalonization, the anti-pattern of usign Avalon
> >too much, even when a more simple solution would make more sense.
> >
> >
>
> Yes. I also think there are many components that actually aren't. If we
> consider some of the subpackages of org.apache.cocoon.components such as
> browser, deli, hsqldb, we can say they aren't component (a
> component-like interface and a single implementation).
>
> So why have they been designed as components ? Because we want to be
> able to choose to include them or not, and if yes, give them some
> configuration. The usual way for this is to define a component and
> configure it in cocoon.xconf, leading to over-componentization. But what
> other way do we have ?
What other way? What about the good old "new Object()"?
> The case or connectors is somewhat different as there are several
> independent implementations have been identified : profiling,
> well-formedness, debug. There is also the Cocoon pipeline probe at
> http://www.pankaj-k.net/cpp which is a transfomer, but could also be
> connector.
>
> >This is the best example: since it's possible to abstract the SAX
> >connections, then we make them components and allow users to plugin
> >their own.
> >
> >Sure it's powerful, but it's *too* powerful. In order to plug them in
> >and write goo ones, they have to know *all* the cocoon internals very
> >well. Since not even us were able to create more than a few non-obvious
> >examples of those components, this is clearly labelling itself as FS.
> >
> >
>
> Having a component to implement a feature doesn't mean that each and
> every user will be able to write its own new implementation, or has to
> know how this component operates. Cocoon comes with a lot of builtin
> features, and the average user chooses which of them to include or not
> using cocoon.xconf (and also the <map:components> of the sitemap).
Yes, but that's becoming too implicit. There is no real difference
between what is required and what can be left out if everything uses the
same mechanism.
> There's an interesting feature in Avalon role management that is IMO not
> enough used : hints, which associate short names to full class names.
Oh, no, I disagree. 'hints' are re-inverting the control and many on
avalon-dev suggest that cocoon should not have been using Avalon for
those cases where it already needed what classes to instantiate.
If avalon is used just as a simpler way to perform classname lookup,
that's not exactly a difficult thing to do ourselves.
> Their use is currently limited to ComponentSelectors, but they could
> also be used in other configurations to avoid naming classes for builtin
> implementations.
No, let's stay away from hints as much as possible.
> Look to the following xconf lines with the eyes of a cocoon newbie. The
> first one is what we currently have with the fully qualified class name,
> and the second one makes use of a hint for that class.
>
> 1 : <pipeline
> class="org.apache.cocoon.components.pipeline.CachingPipeline"/>
> 2 : <pipeline type="caching"/>
>
> What the average user wants is to choose between caching and
> non-caching, i.e. the _feature_ and doesn't care about the actual class
> name (which btw, makes cocoon.xconf unreadable and frightening)
Agreed, totally. But the above is not something that avalon should be
used for because avalon is not a framework for instatiating objects. As
I said, you have java to do that.
> The second line would be easily possible if we added hints in
> cocoon.roles for the implementations of each role built into cocoon.
> This would allow a classname-less cocoon.xconf for standard uses, while
> still allowing advanced users to plug in their own implementations by
> explicitely naming the class.
Hmmm, I dunno, what do others think?
> >Rather, you propose a serious and important issue with
> >'development-oriented pipeline assembly', but this doesn't mean that the
> >user has to know what SAX connector is used for this.
> >
> >
>
> Yes. And as the current SAX connector is not fully suitable for this,
> that's why I'm finally in favor of their removal.
Ok, cool. So I think we have agreement now.
> >It would be enough to have a cocoon configuration trigger that says:
> >
> > - assemble pipelines for maximum performance (means no debug/trace
> >overhead)
> > - assemble pipelines for maximum information (means lots of debug/trace
> >overhead)
> >
> >
>
> And this is where hints come in handy. Imagine such a configuration :
>
> <pipeline type="caching">
> <connection type="profiling"/>
> </pipeline>
>
> We just name the wanted fonctionnality, and not the classes that
> implement it. No "org.apache.cocoon.components.pipeline.CachingPipeline"
> or "org.apache.cocoon.components.saxconnector.ProfilingSAXConnector".
> Just "caching" and "profiling".
Yes, something like this... but I'm skeptical about placing the more
weakly typed indirection for class lookup. We should have more explicit
configurations at the expense of a weaker extensibility but a higher
coherence.
> >So the uses doesn't have to *know* how to do it, but the functionality
> >you wanted is there without the need for overcomponentization which
> >smells like FS too much.
> >
> >How does that sound?
> >
> >
>
> My impression is that FS is smelling stronger when so many classes have
> to be explicitely named by a user that just wants to process XML. A
> broader use of hints would inject simplicity in the xconf without
> sacrificing the flexibility that we need. Cocoon.xconf would then change
> from a class-assembly description to what it really should be, a
> readable and manageable configuration file.
>
> Note also that hints could equally be used in the <map:components> of
> the sitemap. I already proposed this in
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101111373910829&w=2 but
> it didn't had much acceptance at that time because the treeprocessor was
> just born and this was incompatible with the compiled engine.
I agree that classnames are verbose, but hints might become as verbose,
or, if not, might lead to name collisions once we have blocks. So I'm
not a big fan of hints at all.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> <snip/>
>
> Yes. And as the current SAX connector is not fully suitable for this,
> that's why I'm finally in favor of their removal.
>
Ok, so we all agree on removing them, right?
I will do this today.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>
>
>>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 !
>>
>>
>
>I see your point and I agree, but I would like to add a little warning
>to what you're trying to achieve.
>
>Cocoon suffers from overavalonization, the anti-pattern of usign Avalon
>too much, even when a more simple solution would make more sense.
>
>
Yes. I also think there are many components that actually aren't. If we
consider some of the subpackages of org.apache.cocoon.components such as
browser, deli, hsqldb, we can say they aren't component (a
component-like interface and a single implementation).
So why have they been designed as components ? Because we want to be
able to choose to include them or not, and if yes, give them some
configuration. The usual way for this is to define a component and
configure it in cocoon.xconf, leading to over-componentization. But what
other way do we have ?
The case or connectors is somewhat different as there are several
independent implementations have been identified : profiling,
well-formedness, debug. There is also the Cocoon pipeline probe at
http://www.pankaj-k.net/cpp which is a transfomer, but could also be
connector.
>This is the best example: since it's possible to abstract the SAX
>connections, then we make them components and allow users to plugin
>their own.
>
>Sure it's powerful, but it's *too* powerful. In order to plug them in
>and write goo ones, they have to know *all* the cocoon internals very
>well. Since not even us were able to create more than a few non-obvious
>examples of those components, this is clearly labelling itself as FS.
>
>
Having a component to implement a feature doesn't mean that each and
every user will be able to write its own new implementation, or has to
know how this component operates. Cocoon comes with a lot of builtin
features, and the average user chooses which of them to include or not
using cocoon.xconf (and also the <map:components> of the sitemap).
There's an interesting feature in Avalon role management that is IMO not
enough used : hints, which associate short names to full class names.
Their use is currently limited to ComponentSelectors, but they could
also be used in other configurations to avoid naming classes for builtin
implementations.
Look to the following xconf lines with the eyes of a cocoon newbie. The
first one is what we currently have with the fully qualified class name,
and the second one makes use of a hint for that class.
1 : <pipeline
class="org.apache.cocoon.components.pipeline.CachingPipeline"/>
2 : <pipeline type="caching"/>
What the average user wants is to choose between caching and
non-caching, i.e. the _feature_ and doesn't care about the actual class
name (which btw, makes cocoon.xconf unreadable and frightening)
The second line would be easily possible if we added hints in
cocoon.roles for the implementations of each role built into cocoon.
This would allow a classname-less cocoon.xconf for standard uses, while
still allowing advanced users to plug in their own implementations by
explicitely naming the class.
>Rather, you propose a serious and important issue with
>'development-oriented pipeline assembly', but this doesn't mean that the
>user has to know what SAX connector is used for this.
>
>
Yes. And as the current SAX connector is not fully suitable for this,
that's why I'm finally in favor of their removal.
>It would be enough to have a cocoon configuration trigger that says:
>
> - assemble pipelines for maximum performance (means no debug/trace
>overhead)
> - assemble pipelines for maximum information (means lots of debug/trace
>overhead)
>
>
And this is where hints come in handy. Imagine such a configuration :
<pipeline type="caching">
<connection type="profiling"/>
</pipeline>
We just name the wanted fonctionnality, and not the classes that
implement it. No "org.apache.cocoon.components.pipeline.CachingPipeline"
or "org.apache.cocoon.components.saxconnector.ProfilingSAXConnector".
Just "caching" and "profiling".
>So the uses doesn't have to *know* how to do it, but the functionality
>you wanted is there without the need for overcomponentization which
>smells like FS too much.
>
>How does that sound?
>
>
My impression is that FS is smelling stronger when so many classes have
to be explicitely named by a user that just wants to process XML. A
broader use of hints would inject simplicity in the xconf without
sacrificing the flexibility that we need. Cocoon.xconf would then change
from a class-assembly description to what it really should be, a
readable and manageable configuration file.
Note also that hints could equally be used in the <map:components> of
the sitemap. I already proposed this in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101111373910829&w=2 but
it didn't had much acceptance at that time because the treeprocessor was
just born and this was incompatible with the compiled engine.
Thoughts ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>Cocoon suffers from overavalonization, the anti-pattern of usign Avalon
>too much, even when a more simple solution would make more sense.
>
>
+100000000000000000000000000000
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SAXConnector use cases (was Re: [VOTE]: The future of the
SAXConnector)
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> 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 !
I see your point and I agree, but I would like to add a little warning
to what you're trying to achieve.
Cocoon suffers from overavalonization, the anti-pattern of usign Avalon
too much, even when a more simple solution would make more sense.
This is the best example: since it's possible to abstract the SAX
connections, then we make them components and allow users to plugin
their own.
Sure it's powerful, but it's *too* powerful. In order to plug them in
and write goo ones, they have to know *all* the cocoon internals very
well. Since not even us were able to create more than a few non-obvious
examples of those components, this is clearly labelling itself as FS.
Rather, you propose a serious and important issue with
'development-oriented pipeline assembly', but this doesn't mean that the
user has to know what SAX connector is used for this.
It would be enough to have a cocoon configuration trigger that says:
- assemble pipelines for maximum performance (means no debug/trace
overhead)
- assemble pipelines for maximum information (means lots of debug/trace
overhead)
So the uses doesn't have to *know* how to do it, but the functionality
you wanted is there without the need for overcomponentization which
smells like FS too much.
How does that sound?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE]: The future of the SAXConnector
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE]: The future of the SAXConnector
Posted by Berin Loritsch <bl...@apache.org>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> As we have four +1 on b) and no -1, b) is the way to go.
> Everyone agreeing with this?
That's the way I read it.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE]: The future of the SAXConnector
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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?
Carsten
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Thursday, June 27, 2002 12:16 PM
> To: Cocoon-Dev
> Subject: [VOTE]: The future of the SAXConnector
>
>
> Hi,
>
> I refactored the profiling code a little bit, now the
> SAXConnectors are not used anymore for profiling, making
> the use of profiling a little bit easier.
>
> But I think we should now vote for the future of SAXConnectors
> as we already have the (incompatible) changes with the
> handling of event and stream pipelines; so another one in
> this area doesn't hurt.
>
> So, here we go:
>
> a) Deprecate the SAXConnectors and remove it asap.
> b) Remove it now
> c) Change the concept, so that it is possible to configure
> the used SAXConnector on a map:pipeline base.
> d) Leave it as it is
>
> I'm +1 on b) and -1 on d).
>
> c) seems to be FS, but if there is a real need for SAXConnectors
> we should go for c), so this is a +0 on c).
>
> PS: I like clear votes...
>
> Please make your votes.
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org