Hi Andy, On 11/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
But I don't think it is a good idea to divorce the plugin from the DOM. Especially not for a scanf parser solution.
Absolutely wouldn't recommend a scanf parser solution...
But if you were going to go down that route anyways, I would suggest using an XML library. That way you don't have to worry about all the XML issues, like element ordering, invalid XML handling, character encoding, etc. Libxml2 is really nice which is why we chose it for the DOM, but I hear expat is good too, and xerces but it's big and a little slower.
I've used libxml2 for my own projects so certainly would be happy recommending it.
But then you need to write URI handling and resolving code. And ID resolution code. And the COLLADA sid handling code. And the data marshaling with scanf. And maybe some data validation code.
Indeed. Loose useful functionality, for a gain in reducing the external dependencies.
See it's a big can of worms you would be opening. If the OSG community is willing to spend so much effort to do all that work because they are a little frustrated with the COLLADA DOM why don't they put that effort into making the COLLADA DOM better? It's an open source project too. And I would love some help and contributions.
Is there a chance of the DOM licensing being freed up from the requirement to distribute all the docs?
It seems that all of this stems from frustration building the DOM not actually using it. We made a COLLADA DOM binary installer (one for VC7 libs and one for VC8 libs) that will install all of the libs, headers, and the external dependencies (libxml2, iconv, zlib) for you. No more chasing those down yourself. If you don't like the installer the external libs are available for download from the DOM project as a separate archive.
Right now I think the requirement to use the svn version of the DOM is one stumbling blocks.
Then there is the templated daeSafeCast function that creates an error. The function is extremely useful and I found that every COLLADA DOM project I worked on I wrote the function to use. So I thought it should just be part of the DOM so everyone could have that function. As the others have concluded, getting rid of that function (and daeUtils.h entirely) gets rid of that error.
Is there a way we can do an optional compile that picks up on whether daeSafeCast is already defined by the DOM and so do an optional compile of the OSG version?
If it helps any, I think that this COLLADA DOM release is a very stable release and you wont be seeing many changes for quite some time. There are no more memory leaks, no initialization ordering problems (thanks to the OSG community for helping find and fix those errors since they were rare), and all the functionality I believe would be useful to developers. The only changes I see in the near future are performance optumizations (replacing printf and scanf with custom XML schema type io functions that are a lot faster therefore making the DOM load and save a lot faster.)
A stable DOM version would be very useful for 3rd parties like OSG/OSG-users. Do you have a time frame for the next release? If the OSG can help then I'd be happy for OSG users to volunteer themselves to help out ;-) While I'm swamped so can't commit myself to extra stuff like helping out directly with the DOM, I do believe strongly in the need for COLLADA, for it to be well supported across the industry. Standards are very very good thing ;-) Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
