hi, from a xerces and xalan users point of view it is always a blocker for me that both libraries don't share a rich common code base.
in the case of stl both libraries try to reinvent some stl classes on their own. every c++ programmer know stl, but he has to worry about xerces and xalan clones too. that's why i would prefer heavy stl usage in xerces and xalan after verifying which compilers will break _today_. i'm using xerces and xalan on different platforms/compilers (embedded systems too) and never came across stl related problems. btw, i never understand why stl shouldn't work with your pluggable memory management, i always thought that a custom memorymanager to std::allocator wrapper of the allocator template parameter of each stl collection could do the job here, but correct me if i'm wrong, i have never verified this. and this is also for the xalan team, i saw dave is following this conversation: before xerces is pulling in some xpath library like pathan, life could be a lot easier if xalan was sharing the same dom api, so that it could be directly integrated in xerces if users wish xpath/xsl functionality in xerces dom. xalan could implement a special read-only highly optimized xercesc dom instead of creating their own proprietary dom api. xalan should switch to xerces style strings or xerces could move to a xalan domstring style string implementation in 3.0 that xalan can adopt. addtional suggestions for road to 3.0: better net accessor support, because libwww seams dead and current libwww net accessor impl depends on the byte range fetching, which is not very useful for dynamic content cosumption tobias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
