Yeah I'm not completely against the single object idea. I think each method has its own problems. <br><br>I actually think this is most likely one place where we should use branches so different ideas can be tried out/prototyped without effecting trunk. I know there will be the problems with merging the changes back into trunk. But I think here that is most likely the lesser of the evils. As its a very complex and large task to do such changes in trunk. Also I think we would need a least some prototypes of ideas before we got everyones agreement on any approach.<br><br><b><i>Melanie <melanie@t-data.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> I'm against the SOG, personally. I think a clean SceneObject can <br>have group methods and object methods. SOG is one reason the <br>link/unlink code is such a hack!<br><br>SOG is also a showstopper for a clean hierarchical linking
 <br>implementation. The need to handle root objects differently from <br>child objects is a real bother and causes lots of issues with <br>referential integrity.<br><br>An architecture using only one class would be much cleaner, and <br>present a cleaner interface.<br><br>SOG is also at the root of such issues as incorrect object updating <br>to the viewer, loss of child prim inventory, and, actually, every <br>issue related to child prims vs. root prims.<br><br>Considering that a group can be deleted, translated, rotated and <br>scaled,and not much else, those methods would not create too much <br>overhaed on a SceneObject, as it would delegate them to it's parent.<br><br>That is only a small handful of if/then, since, for most operations, <br>all prims are created equal.<br><br>We could still limit the Entities list to root objects, to keep it <br>tolerably small.<br><br>Melanie<br><br><br>Michael Wright wrote:<br>> Yeah, at the time we wrote the SOG/SOP, I was quite
 unsure about having the SOG rather than just linked SOP. But even though the current system has big problems and does need changes. I'm now of the mind that something like the SOG is most likely a good idea. As stefan said the problem with a set of linked SOP's is that there would be so many if/else in there, <br>> <br>> The idea of the SOG, is that if you want to deal with the whole link set (or root) then you could use the SOG, but if you want to deal with one of the separate prims in that group, then you can get its SOP.  Now we all know that things haven't worked out that well. But I'm not sure that is a problem with the actual idea. Just a issue with the implementation and new bits being added over time.<br>> <br>> Stefan Andersson <stefan@tribalmedia.se> wrote:    .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma }  I believe it's time to take that old discussion up again.<br>>   <br>>  The mess called
 SOG/SOP that we have get to know and love came out of a simple question:<br>>   <br>>  * How would we, as application providers, like our object model?<br>>   <br>>  Now, 'we' at that time was mostly me and Darren, so empirical data and peer input was rather scarce.<br>> <br>>  Anyway, at that time, I was still an LSL coder, and one of the things I really hated with LSL was the object model - the notion that an object could change 'role' and thus, you always had to if-then around cases like, 'is this a single object', 'is it a linkset?', 'is it the root object', 'is it attached?' in your code - adn where stuff like 'position' always changed meaning depending on the context. That's what I call 'if-then' coding. And it's bad.<br>>   <br>>  So, when reviewing how scene content was organized, we thought <br>>   <br>>  "we really should have a hierarchihcal model internally, where objects do NOT change behaviour and property meaning. And that model
 should be rendered into protocol-specific representations at the endpoint, ie, in the clientview."<br>>   <br>>  I still think that having an object that represents the object in scene, as opposed to having ten scene objects magically linked on 'root' id is a good idea - especially when considering stuff like mesh-enabled objects, where 'child prims' simply does not apply.<br>>   <br>>  But this time, maybe we should get more discussion. I bid you all ventilate your ideas. And references to other 3D models, and suggestions incorporating how grid, region, scene, avatars, attachments, mesh objects and linksets can work togehter in a single, simple API paradigm are extra welcome.<br>>  <br>> Best regards,<br>> Stefan Andersson<br>> Tribal Media AB<br>>  <br>> Join the 3d web revolution : http://tribalnet.se/<br>> <br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>>
 Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>>  Send instant messages to your online friends http://uk.messenger.yahoo.com <br>> <br>> <br>> ------------------------------------------------------------------------<br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></stefan@tribalmedia.se></blockquote><br><p> Send instant messages to your online friends http://uk.messenger.yahoo.com