Hey,
Neil Graham wrote:
Moving to the future is always good. I am a bit confused though about what "old baggage" we need to shed, and just what shedding implies. The deprecated DOM, for instance, is now built into a separate library; folks that don't need it have no reason to deploy it. Does the inclusion of that unquestionably elderly code in our build manifestly cause anyone pain? If there is other code--aside from things like demonstrably useless enums--that is annoying people, perhaps we could mete the same treatment out to it?
Apart from the things like enums all it is for me is the out of date DOM level 3 stuff and other deprecated methods (such as a couple of the psvi non thread safe ones). Were you thinking of anything else James?
(1) Move to subversion.
I agree that this is beneficial and inevitable. We have clear direction from the Infrastructure team that all projects will eventually be presented with an offer they can't refuse along these lines. That said, as a Cygwin user and a command-line devotee, I'd love to be assured there's hope for my preferred method of code extraction. (Mind you, given the amount I'm committing these days, that hardly matters! :) )
Can you confirm there is no cygwin solution Neil? I don't think we can really move over to subversion if cygwin users cant use it. I certainly would not want to.
(3) HEAD will begin work toward a 3.0 release which sheds old interfaces, etc.
Reiterating the above, I'd like a bit more clarity about the old interfaces we'd like to shed, and just what shedding implies (as well as why it's needed, if shedding == deletion from the source tree).
DOM level 3 certainly does sound like something we should be aiming to support. Looking back at some notes from early 2003, the stimate was that Core would have cost about 3 person months, and load/save about 1 month; given that there has been further divergence since, it's somewhat hard to imagine that these numbers are not conservative. So, before committing ourselves to this course, or to a schedule, it seems to me prudent to estalish that there are volunteers who are able to undertake the necessary work at present.
I can put some time into this. I am also lining up a volunteer or to to help out :) Is there anyone on the list that could help out? Even if we are only talking a day or 2 or some testing / code review it will help.
(On thing I'd love to see resolved for 3.0 would be a re-work of the configure/build infrastructure and ports. Xerces would gain a lot more mindshare if it had a cleaned up ./configure/make/make install build, and a way to lose all of the redundancy that creating a port currently requires.)
I'm very much ready to admit my ignorance of other build architectures. It sure does seem that Xerces-C is supported on lots of platforms and compilers; given that there is a certain amount of investment in the existing infrastructure, I for one would sure be appreciative of some education as to the advantages of alternatives, as well as what's necessary in terms of migration for tooling (build systems etc.) that centre around what we currently have. Understanding a bit more concretely what's wrong with what we currently have would also sure be helpful.
Its certainly non standard. Coming from the Linux world, it irritates me when I have to read docs to install when really I should just have to ./configure/make/make install. Things like the XERCESCROOT cause many mailing list questions and are bit embarrassing. I also think that it would be easier to support new platforms and many more people would do it if it was standard. People who do operate on more obscure systems are used to configure issues and will be more able to solve them. The same cant be said of xerces build issues.
There are other things that I dislike, for example, the fact that the include headers are not in their own directory and have to be copied during build. I find this makes it easier for developers to degrade the boundary between public and private headers.
Gareth
-- Gareth Reakes, Managing Director Parthenon Computing +44-1865-811184 http://www.parthcomp.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
