> > > xml-xerces/java/neko > > > > Makes sense to me. > > I would suggest using "xml-xerces/java/html" instead because > "CyberNeko" is my personal domain and doesn't need to be used > within Apache once it becomes a Xerces2 sub-project. I would > retain the name if it was hosted and developed elsewhere, > though. > > > That's what I was proposing earlier. As I told Andy, you might want to > > take a look at Avalon and Turbine under jakarta to see how they handle > > their subprojects. > > I've been incredibly busy these days but this is definitely > on my list of things to do. > > > xerces-core.jar -> the XNI interfaces and internal machineries > > If this were to only contain the XNI interfaces, then I would > call it "xerces-xni.jar". However, "*-core" is just fine if > this Jar contains other things, such as the "internal machinery" > you mentioned. (BTW, what qualifies as internal machinery?) > > > xerces-sax.jar -> the XML sax parser > > xerces-dom.jar -> the XML DOM provider > > No problem here. > > > xerces-dtd.jar -> the DTD validator > > xerces-schema.jar -> the XMLSchema validator > > Even this is possible. > > > xerces-neko.jar -> the HTML parser > > Depending on where it lives, I would suggest "xerces-html.jar" > instead. > > > xerces-html-dom.jar -> the HTML DOM provider > > xerces-wml-dom.jar -> the WML DOM provider > > Yep.
Sounds like a plan :) > The only issue we need to address is how the user selects > the parser configuration that uses their set of features. hm... > > and no compression added to the jars to speedup classloading > > (compression can be performed over the wire if required) > > We were thinking about compressing the jar files for the > next minor release to see how the world reacts. So far, > you're the only person with a counter argument for why we > shouldn't compress the jar files. > > Which is faster: downloading a compressed jar + decompressing > it OR downloading an uncompressed jar? If the user downloads > the parser from the Net, I would think that uncompressing it > locally is faster than waiting for that many more bytes to > transfer. If the parser is used in a server environment, then > this would be loaded at startup (or first use) and so you only > pay the cost once. The only people adversely affected are those > that bring up separate JVMs and need to re-load the parser jars > every time. > > Therefore, I favor the first option. But of course the needs > of the general community wins. So I'm hoping to hear from more > people that would be affected by this change. So far, I've > heard mostly from people requesting that we compress the jar > files. it will affect the startup time *always* but download time only *once*... ...why not provide both? let the people choose... -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
