Melanie wrote: > Looks like you didn't read my post. I said, as a mid to long range > goal, yes. I didn't say we should never have it. I said it would > block critical fixes if it were forced onto the new region module > interface now.
In your earlier posts you vehemently decried any notion of supplying a scene interface. I hope you haven't forgotten these already. > I'm not bullying anyone. You have not yet had the pleasure of seeing > me bully anyone. :) And I've no interest in trying to discuss something with someone who uses extreme statements without any hint that they can see the other person's point of view. > > Melanie > > Justin Clark-Casey wrote: >> Sean Dague wrote: >>> Melanie wrote: >>>> Hi, >>>> >>>> as a mid to long range goal, +1, actually. >>>> >>>> but in the short run, the ability to load and unload regions is >>>> blocked by the existing module API, and to fix this basic piece of >>>> functionality, they need to be migrated to the new API, asap. >>>> >>>> If this is dragged into a long architectural discussion, we won't >>>> get region restarts for many more months. >>>> >>>> So, I'd rather see this iteration of the region module API pass >>>> Scene, and remove the old API very soon, and then think about >>>> architecting and refactoring when that is not a blocker to >>>> adding/repairing basic functionality. >>> I'd agree with Mel here about lets keep it a bit more open and sloppy >>> for now, and start to lock that down once we're on the other side of the >>> loader issue. >>> >>> We all come to this from different perspectives. Mine is a lot of scars >>> and lost time due to IScriptHost a year ago. Just about every LSL >>> commit required changing IScriptHost and adding back in functions for >>> SOP. Eventually, I just threw out IScriptHost, as it was clear that >>> interface was far too premature. >>> >>> I think we're a bit premature on IScene at this point. We know what we >>> all would do with it, but leaving the barn door open to other random >>> folks abusing the interfaces in ways that we didn't expect is probably >>> reasonable at this stage, so we make sure we don't lock off a piece of >>> function that's very reasonable to want. >>> >>> That being said, breaking Scene into more digestable parts would be a >>> *very good thing*. >> Definitely. I've spent quite some time moving things out of Scene myself. >> Much of what remains are the much more >> indigestible bits (e.g. land/terrain management, inventory). I plan to look >> at these in the course of my normal >> attempts to chip away at the big ball of mud but any help here would be much >> appreciated. >> >> Switching the region module mechanism seemed to me to be a good opportunity >> to introduce a Scene interface without >> causing a separate bout of pain later on. But on hearing some of the >> rational feedback, I accept that it could still be >> too early to do this. If people were to treat this interface as a contract >> they could build against, as Teravus pointed >> out, then it needs to be stable. >> >> Nonetheless, I'm seeing that with the exception of Melanie, the core >> developers who have posted are in favour of having >> an interface eventually (I presume before 1.0). So it is coming and if >> people have to endure some update pain later on, >> well that's the price of building against alpha code. It's not a huge >> upheaval either, in most cases it is simply a >> search and replace of Scene with IScene. When this happens later on I will >> point back at this discussion as warning. >> >> I'm quite happy to hear arguments against a scene interface, but I will >> forcefully counter and later ignore any attempt >> by Melanie to bully me off the point with completely exaggerated statements. >> We're here to discuss, negotiate and >> compromise in good faith, not to shout at each other across the mailing >> lists. >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
