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 [email protected] 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 >> >> [email protected] 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 >>>> >>>> [email protected] wrote: >>>>> Maybe the right name for it is >>>>> OpenSim.Region.ResourceServicesConnectors.dll >>>>> >>>>> [email protected] 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 >>>>>> [email protected] >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> > _______________________________________________ > 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
