We already pull in XML parser dependencies any way If you use GDAL your going to need Xercess, Collada uses either Libxm2 or tinyxml , so for me we already have these in one form or another
I don't really care which one should be adopted but I really don't think we should be writing our own when there are well tested implentations out their As to another 3rd part dependency,I have so many now and OSG is just one its does not make much difference to me, they are typically compile once add to my 3rdparty library VOB and only update when needed which is quite infrequent and OSG is just one of those 3rd part dependencies ) Gordon Product Manager 3d __________________________________________________________ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __________________________________________________________ -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Ciger Sent: Wednesday, May 06, 2009 1:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Robert, Robert Osfield wrote: > > I've never used TinyXML/TinyXML++. I'm certainly open to adopting a > more capable XML parser than the one I've written so far. I'd rather > not add yet another external dependency for core OSG features, which > is why I opted to roll my own XML parser for Present3D (and the .p3d > plugin) rather using libxml2. The dependency is tiny, the code is pretty easy to use: ticpp::Element *fog_e = root->FirstChildElement("fog"); std::string fogname = fog_e->GetAttribute("name"); // get attributes // colour of the fog float r = 0.2, g = 0.2, b = 0.2, a = 1.0; try { ticpp::Element *color = fog_e->FirstChildElement("color"); color->GetAttribute("r", &r); color->GetAttribute("g", &g); color->GetAttribute("b", &b); color->GetAttribute("a", &a); } catch (ticpp::Exception &e) { /* not present */} fmgr->setColor(osg::Vec4(r, g, b, a)); etc. > > Merging TinyXML/TInyXML++ into the core OSG might be a reasonable > thing to do, but only if it's easier to understand and maintain than > rolling this code ourselves. My experience with a writing quick XML > parser suggests that this tasks isn't a big one. I definitely prefer using something like TinyXML or SAX to writing my own parser - parsing trivial files is easy, once you get into obscure things where encodings, schemas and what not that needs to be handled at least to the degree that the parser doesn't choke on it, it is not fun any more. Regarding merging TinyXML into OSG - please, don't! It is very easy to do and a lot of projects do so. This causes crazy problems once you try to combine two libraries that use their own copies of TinyXML, neither has put it into a namespace and the two copies are not identical. I have hit this problem before with ReplicantBody, I believe, and it was a non-trivial issue to deal with. > In the context of port our Collada plugin across to use our own .dae > parsing code I think that the low level parsing code itself is an > order of magnitude less work that the actual work on the dae side. > Tweaking the XML parser classes to support that type of files that > we'll get with dae may well be advantageous i.e. we can make our > parser Matrix/Vec/OSG object aware. That you can do even with a 3rdparty parser - e.g. the code above is parsing the data into OSG data structures. I think that the right way to go is not to avoid a 3rdparty dependency when one is needed at all costs by duplication of work. An XML parser is something so common that I do not see a good reason for creating a yet another incomplete implementation. I understand the pain with dependencies well, but this will only add an extra piece to maintain. Pick a well known, supported and working implementation and stick with it. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKAca0n11XseNj94gRApB9AJ99pbCGUYy7+Bs5xDuxAlI+hdyBiwCggSI/ L0VQS7p9jsXxuck666aONI8= =JcTa -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
