+1 on breaking things more often in trunk. That said, unless we have 'release' tags reasonably up-to-date, people will use trunk and resent opensim for it not working, whatever we tell them.
Best regards, Stefan Andersson > Date: Thu, 30 Apr 2009 00:01:43 +0200 > From: [email protected] > To: [email protected]; [email protected] > Subject: Re: [Opensim-dev] moving away from grid vs. standalone > > 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
