Since I don't have any vetos so far I shall go ahead and create the whiteboard.
- Rajiv -- :wq On Fri, 31 Mar 2000, Arkin wrote: > +1 > > arkin > > Rajiv Mordani wrote: > > > > I have started looking at 1 and 2. One of the proposals that I had was to > > create a whiteboard (won't be part of the std build for xerces so not to > > worry) under xerces-j and make the crimson DOM implementation work with > > xerces and see the outcome. Can we have a round of +1s for that. This > > would also integrate the ElementFactory that someone had asked for earlier > > on the mailing list.. > > > > - Rajiv > > > > -- > > :wq > > > > On Fri, 31 Mar 2000, Mike Pogue wrote: > > > > > Thanks to the folks from Sun for all their hard work in making this > > > happen! Now we have some work to do! :-) > > > > > > The xml-contrib area is designed so that people can look at the code, > > > try it out, etc. The license issues have all been worked out, and the > > > code is now under the Apache 1.1 license, so feel free to look at it, > > > play with it, figure it out, etc. > > > > > > I have a couple of major suggestions (I'm sure that other people have > > > more): > > > > > > 1) It has been reported that the Crimson code is 50% faster than > > > Xerces-J when running on a Sparc Ultra-5, however Xerces-J is 40% faster > > > than Crimson on a Windows NT machine. It's not obvious to me why this > > > would be true! We need to figure out WHY, so we can create a single > > > code base that is fast on BOTH. > > > > > > 2) Crimson has a DOM implementation that is particularly interesting. > > > It has been reported that it "scales better" as the size of an XML > > > document goes up, but that is not my experience (but, I've been looking > > > only at Windows NT, so this could again be a Sparc/Windows difference). > > > This could be due to differences in memory consumption, or something > > > else altogether. We should be able to figure out what's going on here, > > > and get the best of both worlds. Because the Xerces DOM is pluggable, > > > we might need to end up with two DOM's that are optimized for two > > > different things: a) the current deferred DOM is optimized for > > > performance, but maybe not for memory consumption, and b) perhaps the > > > Crimson DOM is optimized for memory consumption. > > > > > > 3) Now that we can see the XHTML code, we should be able to compare > > > Assaf's HTML parser code, and the new Crimson code, so we can end up > > > with the best of both. We routinely get requests for HTML parsing, and > > > this is a pretty self-contained area, so it's a great opportunity to > > > jump in and contribute! > > > > > > All of these things are high on my list -- does anybody want to take a > > > crack at them? This is a great opportunity for some new people to jump > > > in, and check out all the code... > > > > > > Mike > > > > > > P.S. Traffic is now moving to the xerces-j list...please adjust your > > > mailing list subscriptions accordingly! > > > > > > Rajiv Mordani wrote: > > > > > > > > Announicing the release of the code for Crimson XML Parsing Core > > > > Library.. > > > > This code is based on Sun's Java Project X and is available via the cvs > > > > module xml-contrib/crimson for people to look at... Please read the > > > > README > > > > for directions on how to build the source. The list of features to be > > > > included into xerces is yet to be decided. > > > > > > > > - Rajiv > > > > > > > > -- > > > > :wq > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- > ---------------------------------------------------------------------- > Assaf Arkin www.exoffice.com > CTO, Exoffice Technologies, Inc. www.exolab.org > >
