[Opensim-dev] moving away from grid vs. standalone
diva at metaverseink.com
diva at metaverseink.com
Thu Apr 30 15:24:50 UTC 2009
Melanie,
I'm gonna take you on your volunteering to create a skeleton, just like
you did the other time :-) I'm willing to do the extra work of carrying
around 2 monolithic architectures, along with a configurable one, as
long as we can plug them in.
I'll need your help with all the things that this will break, like the
master avie stuff.
Crista
Melanie wrote:
> Well, region modules make the most sense. The new style region modules
> especially, since they have better loading/unloading and are now
> suitable for this.
> Also, region modules can reference each other even when in spearate
> DLLs. So, one packager may want to put LocalComms and GridComms into one
> DLL and not expose any config, while another one may put local comms
> into a dll itself and not ship grid comms at all. yet another may make
> separate DLLs and ref local services in grid services.
>
> Finally, I have an interface in Scene that allows multiple region
> modules to share an interface - the script engines use it. Region
> modules are infinitely flexible there.
>
> So, we don't need
> ILocalUserService
> IGridUserService
> IHGUserService
>
> all we need is
>
> IUserService
>
> Each of the stacked modules can then decide whether it is it's call or
> not. That would be via strings in config, as it is for other region
> modules now. As done in permissions, I have found new semantics to call
> events with return values as well, where I can harvest all return
> values, not just the latest. There is a lot more flexibility in all of
> this than has been used up to now.
>
> I'll be happy to talk about how and create skeletons for this as well.
>
> Melanie
>
>
> diva at metaverseink.com wrote:
>> OK, let me backtrack. There are really two separate issues going on.
>>
>> a) One issue is the means by which we specify different service
>> connectors. The dlls + entry class is the right way. Unfortunately,
>> that isn't in place yet, and I'm not sure I'm the right person to do
>> it :-/
>>
>> b) Another issue is whether Local/OGS1/Hypergrid are really
>> alternatives in the true sense of the word, just like MySql is an
>> alternative to SqlLite, or ODE is and alternative to Bullet. I don't
>> think they are; I think they are generalizations, in that precise order:
>> OGS1=Local+more (you can see this in the dependencies)
>> Hypergrid=OGS1+more (again, see the dependencies)
>> Being generalizations, one can simplify things by having the most
>> general model, and configuring it to obtain the more specific
>> behaviors. (This is independent of how we split the model physically)
>>
>> So, I guess I'm torn here. On the one hand, I can see how things would
>> improve dramatically if we had a plugin thing really going, whatever
>> plugin thing that would be.
>>
>> On the other hand, the plugin thing doesn't exist, and I don't see it
>> on the horizon anytime soon. We're stuck with having to define
>> behavior by configuration variables, instead of dlls. Hence my
>> original proposal, which did *not* include specifying dlls.
>>
>> [I'm having the same feeling I had just before I did RESTComms... so
>> this may very well end up going Melanie's suggestion of region modules
>> again... or I'll just give up trying to fix this in general, and focus
>> on the much narrower things that matter to me which are the security
>> configurations for the hypergrid -- the hell with OGS1]
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
More information about the Opensim-dev
mailing list