Re: [vos-d] reducing number of libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Some downsides to doing this are: 1. The VOS API is supposed to be stabalizing. I don't know if libraries are considered part of the API but anyone who started writing something using 0.22 is going to be annoyed when they upgrade. 2. Now a lot of our documentation, tutorials, etc. are now slightly innacurate and we'll have to update all of those. Reed -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpapOFK83gN8ItOQRAkRJAJ9cZjcIauX7wThzTFHwVHqHhVvHDgCfU9JG uK8mf69FjRcL5F0xE4iFnL8= =Mz5O -END PGP SIGNATURE- ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] reducing number of libraries
Hello all,I think reducing the VOS libs is a good idea, less linking means quicker builds right? As far as I can tell there aren't that many applications using VOS (ter'angreal and betaverse are the only 2 current projects i can think of at the moment) so now would be the time to make serious changes to the API. -Jason ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] reducing number of libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 18 Dec 2005, Jason Moyers wrote: Hello all, I think reducing the VOS libs is a good idea, less linking means quicker builds right? As far as I can tell there aren't that many applications using VOS (ter'angreal and betaverse are the only 2 current projects i can think of at the moment) so now would be the time to make serious changes to the API. It should reduce the compile time of VOS itself, since it won't have to process as many directories. I don't know what effect, if any, it will have on applications actually linking to libvos, although it should obviously reduce the number of you're libraries required to link to :-) [ 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) iD8DBQFDpeICaeHUyhjCHfcRAvXrAJ425Z1EEl7W40RBtMhToJW0dOkO6ACgoy5z 1HEA6FIHOSn2o9FNFRQdZwI= =Ip6d -END PGP SIGNATURE- ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] reducing number of libraries
-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
Re: [vos-d] reducing number of libraries
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: SHA1I 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 toover-modularize and have a proliferation of small libraries.While thismakes 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 actuallycalled 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) andthe new import/export libaries (1 file/1 library for each of XOD, COD andASE).Collapsing the import/export code into a single library is easy.Perhaps a libvosimpexp_3d could have the loader code for ASE, VRML and othersupported formats.I was thinking, though, that the COD and XOD fileformats 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 ofsense 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 atypical VOS app, I'm thinking of merging COD, XOD, vosapp andmetaobject_property into the main libvos. My main concern is over merging the property metaobject.It would add abunch of new files to libvos.From a design standpoint, we've benefittedfrom having the property class be separate, so that none of the core code could treat property vobjects as special.By having the XOD and vosappcode be aware of properties and part of libvos, this would arguably breakthat 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 isessential to being able to interoperate with a VOS site (note that wedidn'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 provethe 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.edu18C21DF7 ]-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDpHPraeHUyhjCHfcRAuF4AKCfcYSE9CfeuHs/4VR1VP0/vwPjRQCghcr7NC11Zf6MQnGL76scAEYW/uQ==ciSh-END PGP SIGNATURE-___vos-d mailing list vos-d@interreality.orghttp://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
