cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Central repository for taglibs
Date Thu, 29 Mar 2001 02:15:33 GMT
On Wed, Mar 28, 2001 at 02:41:13PM +0200, Ulrich Mayring wrote:
> Jeff Turner wrote:
> > 
> > I'm
> > walking on thin factual ice.. better stop, But are any of your taglibs
> > incompatible with old C1 versions?
> Two examples of recent changes that broke my taglibs:
> - redirect behavior was changed
> - OutputStreams were used instead of PrintWriters
> > > So this comes out to nine reference platforms.
> > 
> > That's for Cocoon. Any reason why it should apply to a collection of
> > Cocoon taglibs? Some taglib authors depend on servlet2.2 features, so
> > it would be impractical anyway. In the jakarta-taglibs project, there
> > are already taglibs popping up that depend on 2.3 features.
> So that is an argument for keeping the taglibs with the taglib authors.
> If things really are that fragmented, then I cannot do a better job of
> keeping my taglibs in synch than now. This is due to the additional
> overhead involved in playing with a larger team. There must be something
> that I gain by incurring this additional overhead.

What additional overhead? You're saying "what are the advantages"; I'm saying
"what are the disadvantages" :) Keep in mind the precedent of the very
successful jakarta-taglibs. How does Cocoon's situation differ?

>From a taglib developer's point of view, all that would change is the directory
structure and build system. Occasionally, developers would commit improvements
to CVS. Beyond the initial pain of conforming to a project structure (which I
could take care of), and learning CVS, I can't see the disadvantages.

> If I gain some testers for other reference platforms, then that would be ok.
> If I gain more and better information about changes in Cocoon, then that
> would also be good - however, that could be done right now, too.

I feel like the guy from the union who came around last week ;)
The primary benefit to taglib developers are those that come with success; a
larger user base, contributed fixes, improvements and feedback. Unless the cost
of evaluating taglibs is reduced, this success won't come. Already, there are
JDBC and JNDI taglibs in jakarta-taglibs. XSP is losing it's critical edge in
the eyes of users who largely don't care about SoC. The simplest way I see of
invigorating the taglib world is to reduce the cost of entry.

> > That is the key to why a taglib repository would work:
> > 
> >    ** Issue-specific knowledge cross-cuts taglibs **
> > 
> > These issues can be C2 support, developing good taglib docs, knowledge
> > of schemas, doing cool things with RDDL, fixing Cocoon-specific bugs,
> > clever XSP techniques, etc. Very, very few taglib developers can do
> > all of this. But chances are that, in a group, at least one can do
> > each, and contribute that skill. One person could take responsibility
> > for writing schemas; another could create a schema->documentation
> > system. Another could do RDDL docs for taglibs. I'm not saying all
> > this has to happen for the project to be successful, but it will
> > happen to a much greater extent than if taglibs are not centralized.
> > Yes, I'll fix your, and any other taglib, if the improvement is
> > something I can do.
> Ok, bring on the gurus and I'll come ;-)

You're one of them ;P I can do schemas, docs and RDDL. The rest will come in
time, given a chance.


> Ulrich
> -- 
> Ulrich Mayring
> DENIC eG, Systementwicklung

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message