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

[Melanie]

It's my plan to create the skeleton as a parallel structure. Then 
things can be migrated easily.

Melanie

Dahlia Trimble wrote:
> 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
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev