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 <[email protected]> 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 >> >> [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 >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
