Uh-Oh Diva, Looks like your thread has been severely hijacked ;) I think that what has occurred here is that passions have come to a boil, little misunderstandings have become inflamed into causes of the moment, and the initial goal of the thread has been lost in the chaos.
If I may try to steer it back in that direction, I would say that Diva's question was one of a highly practical, technical nature, and not at all one of philosophy. All she really needs to know is whether 'walled garden' or 'centrally managed grid' is synonymous with the very specific technical terminology 'trust domain'. I will leave it for others to define 'trust domain'. Let us for now say that it represents a pool of security policies. In this somewhat oversimplified description, OSGrid could be defined as a trust domain in which full trust is assumed of everyone. This is analogous to the early days of computing, when user accounts had no passwords. All Diva is attempting to do is to put the uses cases in language that map to specific technically defineable use cases. And yes, Diva, FWIW, I think that your definition and use of trust domain is spot-on in this context ;) Cheers James On Fri, Apr 17, 2009 at 11:44 AM, Mike Dickson <mike.dick...@hp.com> wrote: > And you're being argumentative just to do it. > > Look, OpenSim at least initially was all about the LL grid. Without a > client to access the simulator all the shiny server bits aren't terribly > useful. And there have been a number of starts at other clients. For > the most part however people who connect to OpenSim do it with a LL or > derived viewer. > > If the LL protocol stuff ends up in a forge module (because the > framework can handle that level of separation) I'd be perfectly ok with > that. People will use OpenSim for a variety of projects from running > production traffic (today very likely based on a LL or derived viewer) > to futuristic exploration (like Hypergrid). That's a pretty wide set of > use cases to support. I care more about the process than a specific > product (other than that I can make my product using the framework and > have some semblance of success at it). > > My argument FWIW wasn't about a specific protocol. It's about how it > evolves successfully to support the widely varied use cases OpenSim is > being applied to. Hence the change in subject line. > > Mike > > On Fri, 2009-04-17 at 16:29 +0000, Melanie wrote: > > Hello, > > > > you're basing your argument on a flawed assumption. > > > > OpenSim's purpose is NOT to be a SL clone. It is to be expected that > > OpenSim will evolve away from the LL model in significant ways, > > possibly even before 1.0. > > > > If your desire is to duplicate the LL grid, you can likely still do > > it, and in the future you may need additional modules, which may be > > on forge. > > > > Hypergrid is certainly core, because Hypergrid is what the core team > > sees as the future. SL compatibility is still a focus, but is > > largely understood as a stepping stone into the next generation web. > > > > Therefore, you may well find a "walled garden" forge module in the > > future. > > > > Melanie > > > > > > Mike Dickson wrote: > > > Justin, thanks for clarifying the process. And I certainly understand > > > the interest in Hypergrid and the energy behind it. Charles your > message > > > was also helpful in highlighting to me what is at the center of my > > > concern. I agree the development process is somewhat chaotic and > things > > > get hacked in based on interest. That's probably completely to be > > > expected though it may not make for the best platform going forward. > > > > > > Using Hypergrid as an example,my preference would be to do it outside > of > > > core. So let me explain that. Something like Hypergrid is going to > > > require a different usage model from the original core (different > > > protocols for "teleporting", now the exploration around inventory, > etc). > > > Rather than have the changes to handle that get introduced into core > I'd > > > have preferred to see something like an RFC that documents what is > being > > > proposed, and what "interfaces" need to be changed in order to > > > accommodate the new use cases. That RFC gets iterated and the > > > interfaces evolved to make "hypergrid" possible as a pluggable module. > > > Over time most likely the set of commonly used modules grows and you > > > ultimately end up with a core framework and a "core" set of modules > that > > > define what the out of the box functionality of an installation is > > > (standalone, hypergrid, what have you). > > > > > > The obvious problem with this approach is that it requires evolving the > > > core framework which is not nearly as "sexy" as hacking in new > features. > > > I've done both approaches. Certainly a cool demo can go a long way to > > > sell a concept and often the change the framework process takes enough > > > time that prototypes don't happen. It's more work to maintain a > branched > > > copy of core while you evolve your prototype into a set of changed > > > interfaces that support it. Personally I believe that more disciplined > > > approach is the key to seeing OpenSim get to 1.0. And ultimately be a > > > better platform for experimentation. > > > > > > So I like the concept of hypergrid. I think prototypes like that need > > > to exist if only to prove that the community is healthy. But I also > > > believe that how the "framework" is defined and evolves is equally if > > > not more important (to me at least). > > > > > > Just my 2 cents. > > > > > > Mike > > > > > > On Fri, 2009-04-17 at 15:35 +0000, Justin Clark-Casey wrote: > > >> But I do have to also point out that OpenSim development is largely > driven by the interest of the developers (since > > >> there's no single company behind it). If there's a lot of development > interest behind Hypergrid then this is the > > >> direction that's inevitably going to progress most. If people coming > along contributing code that enhances different > > >> architectures, then development will also be driven in that direction. > > > > > > > > > _______________________________________________ > > > Opensim-dev mailing list > > > Opensim-dev@lists.berlios.de > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > -- > Mike Dickson <mike.dick...@hp.com> > BladeSystem infrastructure R&D > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org http://del.icio.us/SPQR http://twitter.com/jstallings2 http://www.linkedin.com/pub/5/770/a49
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
