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

[Dahlia Trimble]

We need to be careful about how things are broken and make repairs
expeditiously as we also hinder other developers if they are unable to use
their regions for development and testing.

On Wed, Apr 29, 2009 at 3:01 PM, Melanie <melanie at t-data.com> wrote:

> 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/2dd19376/attachment-0001.html>