I think I agree with you Peter, having them as a separate library doesn't make too much sense. You could perhaps use a separate namespace or something?
Beyond reading the mailing lists, I've not been following VOS a huge amount recently. So to answer the question I guess you just have to ask if it is possible to write a useful VOS application that would not use the property metaobject?
Regards
Neil
On 12/17/05, Peter Amstutz <[EMAIL PROTECTED]> wrote:
-----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
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
