Manuel Barros <[EMAIL PROTECTED]> said:
> Hi,
> I don't want to sound pedantic, but I propose a few ideas about how to
> improve Xerces from the client's point of view (the library user and
> contributor).
>
> 1. The MacOS 9 distribution should be supported, all of the underlying
> technologies exist on the Macintosh. Remember, although this is a small
> number of developers, it is nevertheless a strong, and very innovative
group
> of developers who have pioneered numerous of applications we take for
> granted.
Fine, you do the porting work, then submit the patches to us. When we make
a code change the breaks something, you submit a patch to fix it. That's
how it works with lots of other platforms. What we can't do is provide a
binary distribution for every platform.
> 2. Source files should use shorter file names, 32 characters maximum.
The
> Macintosh supports 32 characters as well as other OSes. Also, Windows 95
> already has a 256 character limit for pathnames. Names are easily
> discernable at 32 characters. I submitted a Perl script based on the Mac
> port of Xerces that shortens the file names. I hope its not too much to
ask
> that the class names also be shortened.
We've debated this one endlessly, and I'm still voting no. We made a
conscious decision to make file names the same as the corresponding class
names. I couldn't be less interested in spending lots of time shortening
class names and enforcing some sort of limit. Why not use the PERL script
to shorten the names for those platforms that are problematic instead of
penalizing platforms with modern file systems?
> 3. The Metrowerks compilers should be supported at the very least.
> Metrowerks not only targets the Macintosh, but various embedded OSes,
Palm,
> Linux, and Windows.
Again, you do the porting work, then submit the patches.
> 4. The code base for Xerces and Xalan should converge and use the same
> source base where applicable. Frequently, you will find duplicate
classes
> in Xerces and Xalan which contributes to unnecessary bloat and
complexity.
Well, that might be possible. We've discussed having a common area like
the Java folks do. Why don't you figure out what can be moved in the
commons area and make a concrete proposal?
At any rate, I'd hardly call these proposals "minor" -- they have some
significant impact on the code, and will require major effort from the
committers.
Dave