[Opensim-dev] moving away from grid vs. standalone

[Stefan Andersson]

+1 on breaking things more often in trunk.

That said, unless we have 'release' tags reasonably up-to-date, people will use trunk and resent opensim for it not working, whatever we tell them.

Best regards,
Stefan Andersson




> Date: Thu, 30 Apr 2009 00:01:43 +0200
> From: melanie at t-data.com
> To: diva at metaverseink.com; opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] moving away from grid vs. standalone
> 
> Maybe these things need to be broken. We are almost locked into a 
> rigid schema, now we still have a chance to go to true modularity 
> and we should take it. After all, trunk is meant to be broken :)
> 
> Melanie
> 
> diva at metaverseink.com wrote:
> > I'm also noticing that the region registration with the grid happens 
> > before the post-initialization of the region modules, at least as of 
> > now. In other words, the design has been that Comms would be in place 
> > very early on, so if we change that, it may break all sorts of random 
> > things.
> > 
> > Melanie wrote:
> >> I have done a lot of stuff related to that. Master avatar should not 
> >> even exist in the way it still does today, that is legacy. The very same 
> >> thing can be done in another way (code-wise).
> >> So the existing master avatar stuff can be removed,if that is the only 
> >> blocker, i'll think up some new semantics for that and implement it.
> >> 
> >> Melanie
> >> 
> >> diva at metaverseink.com wrote:
> >>> I think that there is a technical obstacle to doing that: the master 
> >>> avatar stuff, that happens early on in the application (OpenSimBase, 
> >>> line 688), needs to have the communication code in place. I think -- 
> >>> although I may be wrong -- that that happens before region modules are 
> >>> in place.
> >>>
> >>> Melanie wrote:
> >>>> I still think all that stuff can be put in region modules....
> >>>>
> >>>> Melanie
> >>>>
> >>>> diva at metaverseink.com wrote:
> >>>>> Maybe the right name for it is
> >>>>> OpenSim.Region.ResourceServicesConnectors.dll
> >>>>>
> >>>>> diva at metaverseink.com wrote:
> >>>>>> Stefan Andersson wrote:
> >>>>>>> How about
> >>>>>>>  
> >>>>>>> ---
> >>>>>>> [RegionResourceServices]
> >>>>>>> ;GridService = OpenSim.Region.Communications.Hypergrid.dll, 
> >>>>>>> HGGridServices
> >>>>>>> ;GridService = OpenSim.Region.Communications.Local.dll, 
> >>>>>>> LocalBackEndServices
> >>>>>>>  
> >>>>>>> GridService = OpenSim.Region.Communications.OGS1.dll, 
> >>>>>>> OGS1GridServices
> >>>>>>>  
> >>>>>>> [GridService]
> >>>>>>> grid_server_url = "http://192.168.1.101:9000"
> >>>>>>> grid_send_key = "null"
> >>>>>>> grid_recv_key = "null"
> >>>>>>
> >>>>>> The problem with specifying dlls *in this particular case* is that 
> >>>>>> these things aren't entirely orthogonal/different. The Hypergrid 
> >>>>>> dlls are a mashup of the other two. Therefore from a source code 
> >>>>>> perspective it makes things a heck of a lot more complicated than 
> >>>>>> they need to be if we simply merge things and use conditionals on 
> >>>>>> configuration variables. For example, hyperlinks (part of grid 
> >>>>>> services) is a really simple extension to LocalGrid services.
> >>>>>>
> >>>>>> The issue of local vs remote services isn't entirely orthogonal 
> >>>>>> either. Some parts of OGS1 use Local services -- the well know 
> >>>>>> pattern of trying things locally first and if that doesn't work, 
> >>>>>> proceed for a remote service call (e.g. OGS1 grid services does that).
> >>>>>>
> >>>>>> I see why you want this, in abstract. If another service comes 
> >>>>>> along, it can simply be added as a component. Or if someone writes, 
> >>>>>> say, a completely different inventory service, its interface can be 
> >>>>>> added as dll.
> >>>>>>
> >>>>>> But in this particular case, for the code we already have, I think 
> >>>>>> that having Local.dll, OGS1.dll and Hypergrid.dll is not working 
> >>>>>> well, even if the configuration process is the one you suggest. The 
> >>>>>> code is mess; things are _way_ more complicated than they need to be.
> >>>>>>
> >>>>>> So, maybe, what we can do is merging these two ideas. We'll have 
> >>>>>> only one dll (OpenSim.Region.ResourceServices.dll), but we'll 
> >>>>>> specify things in OpenSim.ini the way that you suggest, so that if 
> >>>>>> anyone comes along and wants to plug in a different inventory 
> >>>>>> service, he can just specify the  other dll and an entry class name 
> >>>>>> for it.
> >>>>>>
> >>>>>> What do you think?
> >>>>>>
> >>>>>>
> >>>>>>> [Security]
> >>>>>>>  
> >>>>>>> SessionAuthentication = {True|False}
> >>>>>>> KeyAuthentication = {True|False}
> >>>>>>>
> >>>>>>> ---
> >>>>>>>  
> >>>>>>> The constructor is being fed a config source, so the service can 
> >>>>>>> pick out whatever it needs.
> >>>>>>>  
> >>>>>>> All the shipped grid services could move into one assembly, as 
> >>>>>>> we're explicitly specifying the implementing calss.
> >>>>>>>  
> >>>>>>> I believe this approach would get us improved flexibility.
> >>>>>>>
> >>>>>>> /Stefan
> >>>>>> _______________________________________________
> >>>>>> Opensim-dev mailing list
> >>>>>> Opensim-dev at lists.berlios.de
> >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Opensim-dev mailing list
> >>>>> Opensim-dev at lists.berlios.de
> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Opensim-dev mailing list
> >>> Opensim-dev at lists.berlios.de
> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>
> >>>
> >> 
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> > 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090430/90c024ed/attachment-0001.html>