You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ulrich Mayring <ul...@denic.de> on 2001/03/27 15:59:31 UTC
Central repository for taglibs
Hello,
I was away for two weeks, but saw in the archives that Jeremy proposed a
central repository for taglibs. Did anything come of that or is there no
interest?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Thu, Mar 29, 2001 at 01:55:05AM -0500, Donald Ball wrote:
> On Thu, 29 Mar 2001, Jeff Turner wrote:
>
[..]
> > A separate repository is an obvious need. Taglib committers are usually not
> > Cocoon committers.
>
> i tend to concur. i don't know how willing the pmc will be to hand out
> commit accounts freely to anyone with a logicsheet though. the asf is
> pretty tight about security, with just cause - imagine what a cracker
> could do if he could get malicious code in to either the cvs source tree
> (unlikely) or the packages in the downloads area. using a sourceforge-like
> entity might be the easiest way to at least get this started. i can ask
> the pmc though.
I can see their point. I wonder how jakarta-taglibs got started.
Perhaps Craig McClanahan twisted some arms ;)
OTOH, I agree with Ulrich that any taglibs project without the blessing
of Apache, and without esql, hasn't much chance of gaining momentum.
So to get started, how does this sound: we create a sourceforge project,
populate it with all taglibs whose authors give consent (incl. esql and
ones bundled with Cocoon). Then let this run for three months or so. If
by then the project is still alive, stable, and of sufficient quality,
ask the PMC to vote on it's inclusion in xml.apache.org.
I can see the main sticking point here.. it effectively "forks" all the
official Cocoon taglibs. I see little alternative, or this hasn't got a
chance. Would a promise to religiously keep them in synch, and clearly
indicate any diverging functionality, be enough?
> > And one day you'll spend 24 solid hours tracking down what turns out to be a
> > bug in your version of esql. You'll triumphantly post to the list, and Donald
> > will say "oh yeah, that was fixed in the next version, upgrade from CVS".
> >
> > WHEREAS, if you had got the very latest esql from a separate project,
> > you would know you're getting the latest.
>
> i don't understand how moving the code into a new project would change
> anything - it's already easily possible to download (just the) latest esql
> logicsheet from cvs. in both cases, if you don't download the latest code
> before bug hunting, you might be wasting your time. :)
I'm sure *lots* of people just use the standard taglibs that come with
their distribution. The notion that code from CVS is unstable and
unsupported is widely held, especially at the managerial level ;)
--Jeff
> - donald
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 29 Mar 2001, Jeff Turner wrote:
> > Why wouldn't it? Have you looked at the taglibs? They are frought with
> > if ( cocoon 1.8.x )
> > {
> > do something
> > }
> >
> > else ( cocoon 2.x )
> > {
> > do something else
> > }
> >
> > blocks. What I mean is that the code produced relies heavily on the
> > cocoon version #.
>
> Yes, esql is full of these, because esql is unusually tied to Cocoon
> internals. Esql relies on the pool broker bundled with Cocoon (turbine
> for C1, custom impl for C2). Nevertheless, Donald has managed to keep
> one unified esql in the face of a complete XSP reimplementation,
> proving that even in the most trying circumstances, taglibs can be
> independent of Cocoon versions.
actually, i think context checks like this are very rare - i'm only aware
that the esql logicsheet uses them, and only in two places. c1 and c2 have
different database pool apis - which have nothing to do with xsp per se,
and the get-columns method, which needs to be able to create columns with
names unknown at logicsheet-application-time. xsp doesn't (yet) allow
that, so i do it anyway by touching the xsp engine's "internal" methods.
not really internal per se, just context dependent.
as long as your xsp code uses strictly xsp language elements, doesn't play
with the xsp internal methods, and doesn't need to talk to a cocoon
service, there's no need to worry about context checks.
> A separate repository is an obvious need. Taglib committers are usually not
> Cocoon committers.
i tend to concur. i don't know how willing the pmc will be to hand out
commit accounts freely to anyone with a logicsheet though. the asf is
pretty tight about security, with just cause - imagine what a cracker
could do if he could get malicious code in to either the cvs source tree
(unlikely) or the packages in the downloads area. using a sourceforge-like
entity might be the easiest way to at least get this started. i can ask
the pmc though.
> And one day you'll spend 24 solid hours tracking down what turns out to be a
> bug in your version of esql. You'll triumphantly post to the list, and Donald
> will say "oh yeah, that was fixed in the next version, upgrade from CVS".
>
> WHEREAS, if you had got the very latest esql from a separate project,
> you would know you're getting the latest.
i don't understand how moving the code into a new project would change
anything - it's already easily possible to download (just the) latest esql
logicsheet from cvs. in both cases, if you don't download the latest code
before bug hunting, you might be wasting your time. :)
- donald
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Mar 28, 2001 at 01:57:47AM -0500, Matthew Cordes wrote:
> Hello,
>
> This sounds like an interesting idea, but may prove difficult.
>
> On Wed, Mar 28, 2001 at 04:40:01PM +1000, Jeff Turner wrote:
> >
> > It would be a separate project, like jakarta-taglibs is separate from
> > tomcat-users. Separate CVS, different set of contributors.. why would it
> > affect, or be affected by, the existing Cocoon project infrastructure?
> >
>
> Why wouldn't it? Have you looked at the taglibs? They are frought with
> if ( cocoon 1.8.x )
> {
> do something
> }
>
> else ( cocoon 2.x )
> {
> do something else
> }
>
> blocks. What I mean is that the code produced relies heavily on the
> cocoon version #.
Yes, esql is full of these, because esql is unusually tied to Cocoon internals.
Esql relies on the pool broker bundled with Cocoon (turbine for C1, custom impl
for C2). Nevertheless, Donald has managed to keep one unified esql in the face
of a complete XSP reimplementation, proving that even in the most trying
circumstances, taglibs can be independent of Cocoon versions.
> > I doubt if you'd even find volunteers even to test Cocoon, let alone a whole
> > bunch of taglibs. How does lack of universal testing detract from the benefits
> > of a separate taglibs project? Testing on multiple platforms is one of those
> > "maintenance overheads" that a centralized taglibs project alleviates. To test
> > them all under my environment, I'd go:
>
> I don't understand, I "test" cocoon every day on a few different
> platforms, although using java is supposed to make this unnecessary.
Uli was asking how a taglibs project could
>
>
> >
> > If there was a common taglib repository and mailing list, communication in this
> > area could only improve. Currently, every taglib developer needs to be on top
> > of changes, or risk their taglib being quietly obsoleted. If maintenance was
> > centralized, this is much less likely, as any committer can update multiple
> > taglibs.
>
> I fail to see how another mailing list and repository would help this. It
> would just be 1 more list the developers would have to frequent.
A separate repository is an obvious need. Taglib committers are usually not
Cocoon committers.
A separate mailing list makes sense in the long run, because the current system
is not scalable. Traffic on cocoon-users will only increase, making it
increasingly difficult for taglib-specific discussion to be heard. For similar
reasons, xsp-dev was spun off from cocoon-dev. The tomcat-users / taglibs-user
separation on Jakarta is a clear precedent, and has been very effective in that
context.
> > Perhaps there could be a "Taglib X is known to work in the following
> > environments" page, like Cocoon has.
>
> Call me crazy, but I'd rather download cocoon and know (more or less) the
> taglibs are going to work. I'd rather not have to fetch another package
> and hope they play nice.
And one day you'll spend 24 solid hours tracking down what turns out to be a
bug in your version of esql. You'll triumphantly post to the list, and Donald
will say "oh yeah, that was fixed in the next version, upgrade from CVS".
WHEREAS, if you had got the very latest esql from a separate project, you would
know you're getting the latest.
Again, look at the jakarta-taglibs precedent. It worked for them; I don't see
why it wouldn't work for us.
>
> > It would be interesting to know who's actually using which taglibs. I strongly
> > suspect Tim is right; we are the only ones currently using the LDAP taglib.
> > Perhaps 20 or so currently using ESQL... no wonder there was little reaction to
> > the initial proposal.
>
> I've had no reason to use the LDAP taglib, but I use ESQL nearly every
> day. And is that 20 people at your establishment or 20 cocoon users
> world wide? I'd be surprised if ESQL was not one of the more frequently
> used logicsheets and I'd wager many more than 20 cocoon-users use it.
"Currently developing with at any one time" is what I should have said, and 20
is my highly uninformed estimate.
> I'm more curious how many cocoon users there are in total. Perhaps
> http://xml.apache.org/cocoon could track downloads like the tomcat people
> do for a rough estimate of the size of the userbase.
That would be nice. Or we could just count the ratio of "unsubscribe me" posts.
When it gets as high as tomcat-users, you know you've got a successful project
;)
--Jeff
> -matt
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Matthew Cordes <mc...@maine.edu>.
Hello,
This sounds like an interesting idea, but may prove difficult.
On Wed, Mar 28, 2001 at 04:40:01PM +1000, Jeff Turner wrote:
>
> It would be a separate project, like jakarta-taglibs is separate from
> tomcat-users. Separate CVS, different set of contributors.. why would it
> affect, or be affected by, the existing Cocoon project infrastructure?
>
Why wouldn't it? Have you looked at the taglibs? They are frought with
if ( cocoon 1.8.x )
{
do something
}
else ( cocoon 2.x )
{
do something else
}
blocks. What I mean is that the code produced relies heavily on the
cocoon version #.
>
> I doubt if you'd even find volunteers even to test Cocoon, let alone a whole
> bunch of taglibs. How does lack of universal testing detract from the benefits
> of a separate taglibs project? Testing on multiple platforms is one of those
> "maintenance overheads" that a centralized taglibs project alleviates. To test
> them all under my environment, I'd go:
I don't understand, I "test" cocoon every day on a few different
platforms, although using java is supposed to make this unnecessary.
>
> If there was a common taglib repository and mailing list, communication in this
> area could only improve. Currently, every taglib developer needs to be on top
> of changes, or risk their taglib being quietly obsoleted. If maintenance was
> centralized, this is much less likely, as any committer can update multiple
> taglibs.
I fail to see how another mailing list and repository would help this. It
would just be 1 more list the developers would have to frequent.
> Perhaps there could be a "Taglib X is known to work in the following
> environments" page, like Cocoon has.
Call me crazy, but I'd rather download cocoon and know (more or less) the
taglibs are going to work. I'd rather not have to fetch another package
and hope they play nice.
> It would be interesting to know who's actually using which taglibs. I strongly
> suspect Tim is right; we are the only ones currently using the LDAP taglib.
> Perhaps 20 or so currently using ESQL... no wonder there was little reaction to
> the initial proposal.
I've had no reason to use the LDAP taglib, but I use ESQL nearly every
day. And is that 20 people at your establishment or 20 cocoon users
world wide? I'd be surprised if ESQL was not one of the more frequently
used logicsheets and I'd wager many more than 20 cocoon-users use it.
I'm more curious how many cocoon users there are in total. Perhaps
http://xml.apache.org/cocoon could track downloads like the tomcat people
do for a rough estimate of the size of the userbase.
-matt
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Web services and Cocoon (was: Re: Central repository for taglibs)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> Cool.. it sounds like you're aiming at full-on "web services", SOAP,
> UDDI, WSDL etc.
No, I'm holding off on those until it becomes clear what standard
prevails. The XML protocol group at the W3C will produce something,
probably based on SOAP1.1, and that will probably be what I'll use.
Until then Apache SOAP is fine.
> -- http://xml.coverpages.org/ni2001-03-27-a.html
>
> "Universal printing solution" sounds what you're aiming at.
This is a commercial middleware behemoth from IBM. It may be nice, but
it is not what I believe in :)
> Well.. XML over HTTP works for a lot of people. You just open a socket
> and POST a bunch of XML.
Well, this is a low-level technology, the SOAP taglib and DocHandler are
a generic, high-level framework (using this technique internally, but it
is transparent to the user).
> Hmm.. that sounds useful if it's a generic tool. I've often wanted to
> pass structured data from a HTML form (where XML isn't an option) to a
> servlet, and once invented a mini-language for this (parser written in
> JPython). Berin or someone on cocoon-dev recently proposed an XForms
> project, which this might tie in with.
My personal opinion: forget about XForms (used as a general term, not
relating to the project you mentioned), it will never happen in a
standardized way. There will at one time be an XML interface for HTML
forms, but it will be much more general and on a much higher level of
abstraction. XForms as most people use this term is just a wrapper, like
XHTML is for HTML, it doesn't do zilch, actually :)
When the new samples are up (probably Monday), look at the addressbook
demo. If you want you can already read the docs for it under
http://ulim.cocoonhost.com/taglibs/soap/soap-docs.xml#6 or download the
package.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Web services and Cocoon (was: Re: Central repository for taglibs)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Thu, Mar 29, 2001 at 03:20:43PM +0200, Ulrich Mayring wrote:
> Jeff Turner wrote:
> >
> > I've seen this demo, and it's extremely cool. I doubt if anyone else is
> > pushing web-based, open source xsl:fo this far. This is the type of
> > showcase application that can do wonders for Cocoon PR if it was more
> > widely publicized.
>
> The best is yet to come. The next generation of the DocHandler will
> provide a way to call Cocoon via SOAP, thus getting rid of the
> ProducerFromRequest-paradigm. The PDF archive index will be moved from
> files to a database. These two features already work, but haven't been
> put into production yet. If Ron ever finds the time to give me my own
> mysql login and db tables, I'll be able to upgrade the live samples :)
Cool.. it sounds like you're aiming at full-on "web services", SOAP,
UDDI, WSDL etc.
IBM is very active in this area. A few days ago, they came out with a
"TSpaces Development Kit":
".. to assist the creation, discovery, and integration of Web services.
[..] Development tools provided in the first version of the package
include .. Universal printing solution: a sample printing service that
enables printing from any computer to any printer, regardless of the
host computers (workstations, PCs, handheld devices), operating
systems, or file format."
-- http://xml.coverpages.org/ni2001-03-27-a.html
"Universal printing solution" sounds what you're aiming at.
Wonder how C2 could do as a generic SOAP server, into which SOAP
services could be plugged.
> Also, while it may sound a bit dry, the first feature is very important,
> because it allows me to use Cocoon to generate the PDFs dynamically.
> Now, you might think this is not very hard, just open an URLConnection
> and see what Cocoon gives you. But what if you want to supply parameters
> to Cocoon on how the PDF is supposed to be created? Of course you can
> use HTTP request parameters, but they are flat. So, for example, you can
> never send address data to an XML file via HTTP request parameters,
> since address data needs a more complex structure like:
>
> <address type="person">
> <name>Mayring</name>
> <firstname>Ulrich</firstname>
> ...
> </address>
>
> <address type="company">
> ...
> </address>
Well.. XML over HTTP works for a lot of people. You just open a socket
and POST a bunch of XML.
> This type of structure cannot be encoded in HTTP request parameters,
> unless you do things like
> address1=person&name1=Mayring&firstname1=Ulrich&address2=company&... -
> but this is hardly elegant, hell to maintain and very prone to errors.
> Not to speak of the 1024 character limit for URLs. Alternatively you can
> make one URLConnection per address, but what if I want just one PDF with
> perhaps 1000 addresses on it?
>
> So I devised a way to actually build a rich XML structure like shown
> above and make it possible to pass this to an XML page as parameters.
> Then you can select the bits you need with XSLT and let XSLFO and fop
> make a nice PDF from it. Since this technique is not really related to
> SOAP, I should take it out of the SOAP taglib and make something more
> generic. But first I want to test this in production to see if it is
> easy and stable enough to use.
Hmm.. that sounds useful if it's a generic tool. I've often wanted to
pass structured data from a HTML form (where XML isn't an option) to a
servlet, and once invented a mini-language for this (parser written in
JPython). Berin or someone on cocoon-dev recently proposed an XForms
project, which this might tie in with.
> Next up is to make it so that I can actually print over the Internet,
> not only locally like now. I want to replace lpr with something more
> suited to bulk printing. Then perhaps upgrade the fax feature
> accordingly and implement an emailer. Then I'll open a direct marketing
> firm and draft a W3C standard on XML-based spamming :-)
Wohoo :) "<lies>Make $$$ fast!!</lies>"
--Jeff
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> I've seen this demo, and it's extremely cool. I doubt if anyone else is
> pushing web-based, open source xsl:fo this far. This is the type of
> showcase application that can do wonders for Cocoon PR if it was more
> widely publicized.
The best is yet to come. The next generation of the DocHandler will
provide a way to call Cocoon via SOAP, thus getting rid of the
ProducerFromRequest-paradigm. The PDF archive index will be moved from
files to a database. These two features already work, but haven't been
put into production yet. If Ron ever finds the time to give me my own
mysql login and db tables, I'll be able to upgrade the live samples :)
Also, while it may sound a bit dry, the first feature is very important,
because it allows me to use Cocoon to generate the PDFs dynamically.
Now, you might think this is not very hard, just open an URLConnection
and see what Cocoon gives you. But what if you want to supply parameters
to Cocoon on how the PDF is supposed to be created? Of course you can
use HTTP request parameters, but they are flat. So, for example, you can
never send address data to an XML file via HTTP request parameters,
since address data needs a more complex structure like:
<address type="person">
<name>Mayring</name>
<firstname>Ulrich</firstname>
...
</address>
<address type="company">
...
</address>
This type of structure cannot be encoded in HTTP request parameters,
unless you do things like
address1=person&name1=Mayring&firstname1=Ulrich&address2=company&... -
but this is hardly elegant, hell to maintain and very prone to errors.
Not to speak of the 1024 character limit for URLs. Alternatively you can
make one URLConnection per address, but what if I want just one PDF with
perhaps 1000 addresses on it?
So I devised a way to actually build a rich XML structure like shown
above and make it possible to pass this to an XML page as parameters.
Then you can select the bits you need with XSLT and let XSLFO and fop
make a nice PDF from it. Since this technique is not really related to
SOAP, I should take it out of the SOAP taglib and make something more
generic. But first I want to test this in production to see if it is
easy and stable enough to use.
Next up is to make it so that I can actually print over the Internet,
not only locally like now. I want to replace lpr with something more
suited to bulk printing. Then perhaps upgrade the fax feature
accordingly and implement an emailer. Then I'll open a direct marketing
firm and draft a W3C standard on XML-based spamming :-)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Thu, Mar 29, 2001 at 11:33:02AM +0200, Ulrich Mayring wrote:
> Jeff Turner wrote:
> >
> > 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?
>
> The additional overhead consists of writing a schema, writing
> standardized docs, writing standardized code etc.
Your stuff is 90% there. Think of it as upping the standard of *other*
taglibs to that of yours.
[..]
> > The simplest way I see of invigorating the taglib world is to reduce
> > the cost of entry.
>
> The cost of entry (at least with my taglibs) is currently much lower
> than, say, the cost of entry for esql or the other cocoon taglibs from
> the distro. I have docs that are very readable and understandable even
> though they are not standardized.
Yes, you rather break my nice stereotype, dammit ;) But users can't
*tell* until they've tried it, and often will assume the worst. I'd
guess "perceived" cost of entry is almost as important as the real cost.
Guaranteeing a standardized build and documentation system goes a long
way in reducing this.
> I have many samples that work out of the box, even a complete
> application that manages a PDF archive and can print, fax, save,
> retrieve and create PDF documents. I put the time I saved on
> standardization into clarity, expressiveness and completeness (sort of
> ;-)
I've seen this demo, and it's extremely cool. I doubt if anyone else is
pushing web-based, open source xsl:fo this far. This is the type of
showcase application that can do wonders for Cocoon PR if it was more
widely publicized.
For those wondering, have a look at http://ulim.cocoonhost.com, in
particular http://ulim.cocoonhost.com/soap-live/xml/index.xml
--Jeff
[..]
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> 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?
The additional overhead consists of writing a schema, writing
standardized docs, writing standardized code etc.
> 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.
Yeah, but if I just check my stuff in the way it is, then it won't
conform to anything :)
> 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.
The cost of entry (at least with my taglibs) is currently much lower
than, say, the cost of entry for esql or the other cocoon taglibs from
the distro. I have docs that are very readable and understandable even
though they are not standardized. I have many samples that work out of
the box, even a complete application that manages a PDF archive and can
print, fax, save, retrieve and create PDF documents. I put the time I
saved on standardization into clarity, expressiveness and completeness
(sort of ;-)
The advantages of a central repository are largely targeted at
developers, not at users. Users don't care how the stuff is maintained
and whether the docs conform to a schema.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
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.
--Jeff
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Ulrich Mayring <ul...@denic.de>.
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. 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.
> You don't have to. The advantages of a taglib repository are that of a
> consistent build, examples, documentation and (for 2.2 users) testing
> system.
Hm, well. Sounds like much refurbishment for my taglibs :)
> A counter-question: are you going to upgrade your taglibs to support
> C2 soon? ;) I presume not, because it's not something you need. If
> they were in a central project, it only takes one C2 guru (with a lot
> of spare time) to get the whole lot, including yours, working with C2.
If that guru is there, great. But I currently don't see him :)
> 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 ;-)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Mar 28, 2001 at 10:09:37AM +0200, Ulrich Mayring wrote:
> Jeff Turner wrote:
> >
> > It would be a separate project, like jakarta-taglibs is separate
> > from tomcat-users. Separate CVS, different set of contributors..
> > why would it affect, or be affected by, the existing Cocoon
> > project infrastructure?
>
> Taglibs are inseperable from Cocoon. Think of the most widely used
> taglibs like sql or esql - Donald can make sure that esql runs with
> every new release, because he is on top of the developments of
> Cocoon and can, if need be, change something in Cocoon to benefit
> his taglib.
I didn't think esql, for example, and Cocoon were that tightly
coupled. What sort of dependencies are you thinking of?
I'd have thought that it's not so much "what new stuff has Cocoon got
that breaks my taglib", but more "what new XSP features can I use that
will break backwards-compatibility". That's the decision of the taglib
author. If esql x.x won't work with later versions of Cocoon, might as
well bundle it with the version that works. The vast majority of
taglibs, I'd guess, are not tied to Cocoon versions at all. XSP
enhancements in C1 have been mostly cosmetic or under the hood. I'm
walking on thin factual ice.. better stop, But are any of your taglibs
incompatible with old C1 versions?
> > By reference platform, I assume you mean Tomcat, JRun, Resin, etc?
>
> I quote from the website:
>
> All new code should be tested under the following servlet engines:
>
> - Apache JServ 1.1.2 (NOTE: This uses Servlet API 2.0) - Apache
> Tomcat 3.1
> - Resin 1.2.0
>
> It should also be tested on the following:
>
> - A Windows operating system
> - A UNIX-type operating system
> - A JDK version 1.1.x
>
> 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.
Of course that doesn't mean certain taglibs can't mandate a level of
backwards-compatibility. I'd imagine you'd get upset if someone added
2.2 code to your taglibs :)
> > I doubt if you'd even find volunteers even to test Cocoon, let
> > alone a whole bunch of taglibs. How does lack of universal testing
> > detract from the benefits of a separate taglibs project? Testing
> > on multiple platforms is one of those "maintenance overheads" that
> > a centralized taglibs project alleviates. To test them all under
> > my environment, I'd go:
> >
> > cd xsp-taglibs
> > ./build.sh dist
> > cp dist/*.war /var/tomcat/webapps
> > tomcat stop ; tomcat start
> >
> > Much easier than anything possible today.
>
> How would that apply to JServ and Resin?
It would work fine for Resin, and any servlet2.2-compliant server.
JServ, obviously not, but see my question above as to why taglibs must
be tied to Cocoon platform requirements. The point of the above
example is that a taglib repository makes testing a lot easier *in
most cases*, and no harder in the JServ case.
> And why should I test taglibs that I don't use? I test my own
> taglibs on my platform and for esql I trust Donald :)
You don't have to. The advantages of a taglib repository are that of a
consistent build, examples, documentation and (for 2.2 users) testing
system.
> > If there was a common taglib repository and mailing list,
> > communication in this area could only improve. Currently, every
> > taglib developer needs to be on top of changes, or risk their
> > taglib being quietly obsoleted. If maintenance was centralized,
> > this is much less likely, as any committer can update multiple
> > taglibs.
>
> Cool, so you will fix my taglibs? :)
A counter-question: are you going to upgrade your taglibs to support
C2 soon? ;) I presume not, because it's not something you need. If
they were in a central project, it only takes one C2 guru (with a lot
of spare time) to get the whole lot, including yours, working with C2.
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.
Sadly, all I can do *well* is documentation ;P Hence the long-winded
emails..
--Jeff
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> It would be a separate project, like jakarta-taglibs is separate from
> tomcat-users. Separate CVS, different set of contributors.. why would it
> affect, or be affected by, the existing Cocoon project infrastructure?
Taglibs are inseperable from Cocoon. Think of the most widely used
taglibs like sql or esql - Donald can make sure that esql runs with
every new release, because he is on top of the developments of Cocoon
and can, if need be, change something in Cocoon to benefit his taglib.
> By reference platform, I assume you mean Tomcat, JRun, Resin, etc?
I quote from the website:
All new code should be tested under the following servlet engines:
- Apache JServ 1.1.2 (NOTE: This uses Servlet API 2.0)
- Apache Tomcat 3.1
- Resin 1.2.0
It should also be tested on the following:
- A Windows operating system
- A UNIX-type operating system
- A JDK version 1.1.x
So this comes out to nine reference platforms.
> I doubt if you'd even find volunteers even to test Cocoon, let alone a whole
> bunch of taglibs. How does lack of universal testing detract from the benefits
> of a separate taglibs project? Testing on multiple platforms is one of those
> "maintenance overheads" that a centralized taglibs project alleviates. To test
> them all under my environment, I'd go:
>
> cd xsp-taglibs
> ./build.sh dist
> cp dist/*.war /var/tomcat/webapps
> tomcat stop ; tomcat start
>
> Much easier than anything possible today.
How would that apply to JServ and Resin? And why should I test taglibs
that I don't use? I test my own taglibs on my platform and for esql I
trust Donald :)
> If there was a common taglib repository and mailing list, communication in this
> area could only improve. Currently, every taglib developer needs to be on top
> of changes, or risk their taglib being quietly obsoleted. If maintenance was
> centralized, this is much less likely, as any committer can update multiple
> taglibs.
Cool, so you will fix my taglibs? :)
Seriously, I think we both agree except on the order of events. I say
"fix the Cocoon project and then make a taglibs project" and you say
"make the taglibs project and fix the Cocoon project later" :)
> It would be interesting to know who's actually using which taglibs. I strongly
> suspect Tim is right; we are the only ones currently using the LDAP taglib.
> Perhaps 20 or so currently using ESQL... no wonder there was little reaction to
> the initial proposal.
Yeah, that's why I said I'd make it dependent on whether I find enough
users for testing on all the reference platforms. This is IMHO a good
indicator.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Mar 28, 2001 at 01:01:39AM +0200, Uli Mayring wrote:
> On Wed, 28 Mar 2001, Jeff Turner wrote:
>
> > Did Jeremy propose one too? I made a proposal
> > (http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=98526568823734&w=2), but
> > nothing has come of it so far.
>
> Jeremy, Jeff, them Gringos all look the same ;-)
>
> Seriously, it is a good proposal, but the structure of the Cocoon project
> is not up to it yet. It would mean a large number of new contributors to
> the project, most of them probably less familiar with Cocoon itself than
> the current developers. It doesn't matter whether you "officially" do this
> outside of the Cocoon project, in every practical sense it will be part of
> it.
It would be a separate project, like jakarta-taglibs is separate from
tomcat-users. Separate CVS, different set of contributors.. why would it
affect, or be affected by, the existing Cocoon project infrastructure?
> We need to evolve the administrative side of the Cocoon project some more
> before taking a step like this. The good things that have happened:
>
> - we have a set of reference platforms
> - we have a patch queue system
> - we have links to existing taglibs on the Cocoon website
>
> What still needs to be done:
>
> - for each reference platform one user must be identified to test all the
> supplied samples on it with every new release of Cocoon
By reference platform, I assume you mean Tomcat, JRun, Resin, etc?
> - one user must be identified, who agrees to test one taglib on one
> reference platform with each new release of either taglib or Cocoon. If we
> do not find these users, then the taglib is not used widely and should for
> the time being kept out of this system
I doubt if you'd even find volunteers even to test Cocoon, let alone a whole
bunch of taglibs. How does lack of universal testing detract from the benefits
of a separate taglibs project? Testing on multiple platforms is one of those
"maintenance overheads" that a centralized taglibs project alleviates. To test
them all under my environment, I'd go:
cd xsp-taglibs
./build.sh dist
cp dist/*.war /var/tomcat/webapps
tomcat stop ; tomcat start
Much easier than anything possible today.
> - a communication system has to be established that makes sure taglib
> authors are notified of each change within Cocoon, so they can see if it
> affects their taglib. Preferably this communication system should not
> consist of a subscription to cocoon-dev. Perhaps there could be a
> cocoon-changes list.
If there was a common taglib repository and mailing list, communication in this
area could only improve. Currently, every taglib developer needs to be on top
of changes, or risk their taglib being quietly obsoleted. If maintenance was
centralized, this is much less likely, as any committer can update multiple
taglibs.
> As for my own taglibs, auth and soap, I'd contribute them to any sensible
> system, but I'm not going to test on each of the reference platforms. I
> have enough to do to test on my own platform, as I currently have no way
> to inform myself on the changes made to Cocoon (the changes.xml file
> doesn't contain everything and not in sufficient detail).
Perhaps there could be a "Taglib X is known to work in the following
environments" page, like Cocoon has.
> If there are no users out there willing to test my stuff on the other
> reference platforms, then my taglibs are simply not popular enough and can
> remain under my thumb :)
It would be interesting to know who's actually using which taglibs. I strongly
suspect Tim is right; we are the only ones currently using the LDAP taglib.
Perhaps 20 or so currently using ESQL... no wonder there was little reaction to
the initial proposal.
--Jeff
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Softwareentwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Uli Mayring <ul...@denic.de>.
On Wed, 28 Mar 2001, Jeff Turner wrote:
> Did Jeremy propose one too? I made a proposal
> (http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=98526568823734&w=2), but
> nothing has come of it so far.
Jeremy, Jeff, them Gringos all look the same ;-)
Seriously, it is a good proposal, but the structure of the Cocoon project
is not up to it yet. It would mean a large number of new contributors to
the project, most of them probably less familiar with Cocoon itself than
the current developers. It doesn't matter whether you "officially" do this
outside of the Cocoon project, in every practical sense it will be part of
it.
We need to evolve the administrative side of the Cocoon project some more
before taking a step like this. The good things that have happened:
- we have a set of reference platforms
- we have a patch queue system
- we have links to existing taglibs on the Cocoon website
What still needs to be done:
- for each reference platform one user must be identified to test all the
supplied samples on it with every new release of Cocoon
- one user must be identified, who agrees to test one taglib on one
reference platform with each new release of either taglib or Cocoon. If we
do not find these users, then the taglib is not used widely and should for
the time being kept out of this system
- a communication system has to be established that makes sure taglib
authors are notified of each change within Cocoon, so they can see if it
affects their taglib. Preferably this communication system should not
consist of a subscription to cocoon-dev. Perhaps there could be a
cocoon-changes list.
As for my own taglibs, auth and soap, I'd contribute them to any sensible
system, but I'm not going to test on each of the reference platforms. I
have enough to do to test on my own platform, as I currently have no way
to inform myself on the changes made to Cocoon (the changes.xml file
doesn't contain everything and not in sufficient detail). If there are no
users out there willing to test my stuff on the other reference platforms,
then my taglibs are simply not popular enough and can remain under my
thumb :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Central repository for taglibs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Mar 27, 2001 at 01:59:31PM +0000, Ulrich Mayring wrote:
> Hello,
>
> I was away for two weeks, but saw in the archives that Jeremy proposed a
> central repository for taglibs. Did anything come of that or is there no
> interest?
Did Jeremy propose one too? I made a proposal
(http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=98526568823734&w=2), but
nothing has come of it so far.
--Jeff
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>