On Feb 10, 2005, at 5:32 AM, Gareth Reakes wrote:
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?
No, that's what I was thinking about. My reasoning goes like this: we can't change interfaces without a bump in the major version; there is increasingly call to cleanup the interfaces. In making this proposal, I'm trying to further dialogue in the community about where Xerces should go next. This does not come from a heart-felt need of mine, personally, that we necessarily have to break the interface (necessitating a 3.0 version).
I guess the question people should respond to is:
- Is the interface "broken" enough that it's worth it to break compatibility (somewhat) and move to a 3.0 version?
Some other aspects of desired cleanup (such as reorganization of includes, for instance), would probably also mandate a move to 3.0.
For me, a re-think and re-construction of the build and port infrastructure would be enough justification, on it's own, to move to 3.0, as it represents a major facelift to the xerces-c experience.
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.(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! :) )
Subversion is "widely available". This includes command line access under cygwin and UI under windows. See http://www.hisp.info/confluence/display/DHIS2/Subversion, for instance (that's just one of many links I found on google). Also see the "clients" section of the subversion book: http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ap-d-sect-1.
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.(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.(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.
Yes, we support xerces on lots of compilers and architectures. But the way we do it involves lots of duplicated code, lots of special casing, etc.
The canonical way to build and install a project these days is with:
./configure && make && make install
Xerces doesn't get there, requiring special flags to a tool that wraps configure, which doesn't really get used appropriately.
There are two major things that need to be fixed in the build-infrastructure:
(1) Refactor platform support to eliminate or reduce duplication, relying instead, and where needed, on flags generated through the configuration process.
(2) Rebuild the build/configuration/install stages to support the canonical build/install and eliminate the requirement for things like XERCESCROOT.
In doing this all of this, additional items should be considered, such as:
a. Are there elements of platform support that can be eliminated? (I would consider dropping support in 3.0 for Mac Classic systems, for instance, which would greatly simply the Mac port)
b. Are we installing headers/libraries, etc, where appropriate?
In rebuilding, we'll likely break some ports for a while. My approach would probably be to strip-out explicit platform support and then add it in carefully as needed, attempting to rely on autoconf to for necessary customization. We'll likely get a lot of platform/architecture support, for free, that we work very hard to achieve today (and which leads to code duplication, difficulty in porting to new platforms, etc).
I'm willing to take a first-pass at a new build infrastructure and re-factoring. Following that, it's going to require testing and (perhaps) re-porting of various platformas/architectures/compilers to the new system. But, as I tried to explain above, this task should be much simpler (or even unneeded in many cases) with a true autoconf based build.
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.
Yes, Gareth, I agree.
To summarize what I've heard/said so far:
Potential feature additions/fixes for 3.0:
- Reorganization of public/private includes
- Revisiting of install locations
- Refactoring of x-platform support
- A true autoconf-based build infrastructure
- Add a libcurl based netaccessor?
- Add DOM 3.0 support?Potential feature/interface deletions:
- Remove deprecated DOM altogether.
- Remove and/or update deprecated enums
- Remove non-thread-safe psvi methods.
- Remove Mac OS Classic support (supporting Mac OS X only for 3.0).Anything else bold that needs to be done? Integral xpath support anyone?
James.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
