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 > > > [email protected] 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 >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
