-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I got a big whack of coding done last night, which was very satisfying :-) Something that occurred to me, though, was the current tendency in VOS to over-modularize and have a proliferation of small libraries. While this makes sense for dynamically loaded plugins, it's annoying if you have to list 10 libraries on the link line to pull in all the features you need. Worse, certain libraries which register themselves with VOS arn't actually called by your app, and so won't generate link errors if they are missing. The wost offenders I'm thinking of right now are libvosapp (1 file) and the new import/export libaries (1 file/1 library for each of XOD, COD and ASE).

Collapsing the import/export code into a single library is easy. Perhaps a libvosimpexp_3d could have the loader code for ASE, VRML and other supported formats. I was thinking, though, that the COD and XOD file formats are really are generic core feature and should probably be put into the main libvos. XOD, however, relies on the Property metaobject.

Vosapp is also now a one file library, and would probably make a lot of sense to be merged into the main libvos. This also has a direct dependency on the Property metaobject, though.

So, with the goal of reducing the number of link libraries involved in a typical VOS app, I'm thinking of merging COD, XOD, vosapp and metaobject_property into the main libvos.

My main concern is over merging the property metaobject. It would add a bunch of new files to libvos. From a design standpoint, we've benefitted from having the property class be separate, so that none of the core code could treat property vobjects as "special". By having the XOD and vosapp code be aware of properties and part of libvos, this would arguably break that encapsulation slightly.

On the other hand, it could be fairly argued that the property metaobject is for all intents and purposes a core feature. At this point, it is essential to being able to interoperate with a VOS site (note that we didn't know this would be the case when we originally designed VOS, which was why it was put as a separate optional module back then.)

I would say that the wall between them has held up long enough to prove the point, so it would make sense, and ultimately make everyones lives a bit easier, if the property metaboject were made part of the core libvos.

Comments?

[   Peter Amstutz   ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDpHPraeHUyhjCHfcRAuF4AKCfcYSE9CfeuHs/4VR1VP0/vwPjRQCghcr7
NC11Zf6MQnGL76scAEYW/uQ=
=ciSh
-----END PGP SIGNATURE-----


_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

Reply via email to