[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