> > Right! So no nasty object tracking and parcel researching (by > > default) please... > > It doesn't do either of those by default as far as I know.
Okay, bad choice of words on my part. The ObjectManager is instantiated by default, which registers a number of callbacks to automatically decode objectupdate packets. The same appears to be done for Parcels, and a number of other managers. Each of these Managers registers a number of call backs, quite a few in total. In my humble opinion to make testing of the library easier, to make benchmarking easier, and to give developers better control of what the library is doing -- these Managers should either not be instantiated by default, or if they are, they should not register callbacks to decode pacets unless the developer using the library specifically requests them to do so. The specific example of the ObjectManager was that it was added, and then put into place as something that is instantiated by default. This caused a number of callbacks to get registered, that then started spitting out warning messages. The processing of those callbacks, also effected (very slightly) the performance of the library when measuring other activities that were going on. I really like the work going on for the ObjectManager, and will be making use of it fairly soon myself. But I also like to have complete control over exactly what my applications are doing, and to have additional functionally added that just automatically starts doing additional processing -- is somewhat vexing. :-) Alternatively, if it's prefered that the library do as much as possible by default, and that control is granted to user's of the library by allowing them to turn things off -- then I should add the Asset, Image, and Inventory mangers to be loaded by default. This will cause about a dozen more callback handlers to be registered, and will cause Asset, Image and Inventory packets to be processed automatically. It would not cause any assets, or inventory data to be automatically requested -- just as registering the objectmanager does not. I'm willing to work either way, I just need to know what the concensus of the group is. -- Mike C. _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
