a few comments:
1 in the sandbox, anything goes.
2 if i18n depends on xmlio then xmlio needs to promoted and released before i18n is. so, it's important that xmlio has a good chance of being promoted and that any possible issues are discussed now.
3 alternatives are good but direct competitors are bad. we are short of developer energy here in the commons and components in the same area should share a community and coorperate rather than fight for mind share. fights for mind share between direct open source competitors can turn very nasty. we've (so far) managed to keep quite a healthy community here in the commons and i'm very keen to keep it this way. therefore, saying that xmlio needs a place in the commons because it's better than digester does make me worried. in the past, components pushed in this manner have tended to end up finding homes elsewhere.
4 users are going to ask: should i use digester (betwixt, JXPath, xmlbeans, jaxme) or xmlio? we should be able to clearly and fair describe and explain the differences if we are going to have two components. if digester and xmlio really are direct competitors (no substantial conceptual or philosophical differences, just implementation ones) then it would be better to rename xmlio digester 2 (packaged under the org.apache.commons.digester2). digester (1) is mature now and it's not really possible to push it much further. work on a combined digester 1 replacement could then start as digester 3 (packaged under rg.apache.commons.digester3).
- robert
On 7 Oct 2004, at 23:46, Martin Cooper wrote:
On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne <[EMAIL PROTECTED]> wrote:One of the key items in the commons charter is allowing different solutions
to the same problem. So far, we have tended to avoid this (for example, I
took a conflicting primitives design elsewhere) however we should not block
this.
What is being requested at this point is to factor out some code from
another project (Slide) to commons. This is IMHO perfectly good and what
commons is for. The code is going to the sandbox where we can all determine
whether it is a good addition to the commons-proper fold. (eg. performance
tests, code design, documentation). Who knows maybe the ideas will end up as
digester 2! IMO thats what the sandbox is for.
In general, I agree with you. However, in this case, the reason for bringing this component to the sandbox is because another component that has only just arrived in the sandbox (i18n) wants to use it instead of Digester. It seems that this XML component wasn't going to be brought to Commons (at least for the moment) until there was mention that i18n wanted to use it.
I'm not sure that I like the idea of new sandbox components bringing along other components as baggage when there is already suitable functionality available in Commons Proper. On the other hand, I would not be opposed to bringing the XML component in _later_, and letting it stand or fall on its own.
-- Martin Cooper
BTW, I don't disagree with the comments about bad dependency management
below, I just disagree that that necessarily implies only ever supporting
digester.
Finally, the name ;-) xmlio (ie. xml io) sax saxio
Typically, the commons project is named after the technology it works on.
Without having seen the code its also difficult to judge what a good name
would be ;-) I quite like xmlio myself.
Stephen
----- Original Message ----- From: "David Graham" <[EMAIL PROTECTED]>This will create bloat problems for clients that use Digester. For
example: Struts uses Digester for xml parsing. In the future Struts may
want to use the new i18n component. However, if i18n uses XML Im-Exporter
then Struts must drag that along too despite already having a perfectly
fine xml parser in its dependency list.
Struts is just one example. It will be even worse for inter-commons project dependencies.
Bad dependency management has plagued commons components and it's just
recently started to get better. If all commons components use Digester
then we can avoid having to duplicate functionality and bloat
dependencies.
I don't understand what's wrong with Digester that necessitates a new parsing library. I've been able to write complex parsing rules in a matter of minutes.
David
--- Oliver Zeigermann <[EMAIL PROTECTED]> wrote:
Folks,
on the request of Daniel Florey I'd like to create at least one new sandbox component for a tool that allows easy import / export of XML into / from Java. It is used by Jakarta Slide and in the components Daniel introduced.
I know this is a bit delicate as there already is Digester around in
commons. However, the audience for my tool is different from
Digester's. XML Im-/Exporter is geared towards high performance use
for people who are very familiar with XML. It is just a little bit
more than pure SAX. It also has a different philosohie than Digester.
Having said that I hope not to cause any inconvenience with this...
Preparing this now and cheers,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
