<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
+1 on breaking things more often in trunk.<br><br>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.<br><br>Best regards,<br>Stefan Andersson<br><br><br><br><br>> Date: Thu, 30 Apr 2009 00:01:43 +0200<br>> From: melanie@t-data.com<br>> To: diva@metaverseink.com; opensim-dev@lists.berlios.de<br>> Subject: Re: [Opensim-dev] moving away from grid vs. standalone<br>> <br>> Maybe these things need to be broken. We are almost locked into a <br>> rigid schema, now we still have a chance to go to true modularity <br>> and we should take it. After all, trunk is meant to be broken :)<br>> <br>> Melanie<br>> <br>> diva@metaverseink.com wrote:<br>> > I'm also noticing that the region registration with the grid happens <br>> > before the post-initialization of the region modules, at least as of <br>> > now. In other words, the design has been that Comms would be in place <br>> > very early on, so if we change that, it may break all sorts of random <br>> > things.<br>> > <br>> > Melanie wrote:<br>> >> I have done a lot of stuff related to that. Master avatar should not <br>> >> even exist in the way it still does today, that is legacy. The very same <br>> >> thing can be done in another way (code-wise).<br>> >> So the existing master avatar stuff can be removed,if that is the only <br>> >> blocker, i'll think up some new semantics for that and implement it.<br>> >> <br>> >> Melanie<br>> >> <br>> >> diva@metaverseink.com wrote:<br>> >>> I think that there is a technical obstacle to doing that: the master <br>> >>> avatar stuff, that happens early on in the application (OpenSimBase, <br>> >>> line 688), needs to have the communication code in place. I think -- <br>> >>> although I may be wrong -- that that happens before region modules are <br>> >>> in place.<br>> >>><br>> >>> Melanie wrote:<br>> >>>> I still think all that stuff can be put in region modules....<br>> >>>><br>> >>>> Melanie<br>> >>>><br>> >>>> diva@metaverseink.com wrote:<br>> >>>>> Maybe the right name for it is<br>> >>>>> OpenSim.Region.ResourceServicesConnectors.dll<br>> >>>>><br>> >>>>> diva@metaverseink.com wrote:<br>> >>>>>> Stefan Andersson wrote:<br>> >>>>>>> How about<br>> >>>>>>> <br>> >>>>>>> ---<br>> >>>>>>> [RegionResourceServices]<br>> >>>>>>> ;GridService = OpenSim.Region.Communications.Hypergrid.dll, <br>> >>>>>>> HGGridServices<br>> >>>>>>> ;GridService = OpenSim.Region.Communications.Local.dll, <br>> >>>>>>> LocalBackEndServices<br>> >>>>>>> <br>> >>>>>>> GridService = OpenSim.Region.Communications.OGS1.dll, <br>> >>>>>>> OGS1GridServices<br>> >>>>>>> <br>> >>>>>>> [GridService]<br>> >>>>>>> grid_server_url = "http://192.168.1.101:9000"<br>> >>>>>>> grid_send_key = "null"<br>> >>>>>>> grid_recv_key = "null"<br>> >>>>>><br>> >>>>>> The problem with specifying dlls *in this particular case* is that <br>> >>>>>> these things aren't entirely orthogonal/different. The Hypergrid <br>> >>>>>> dlls are a mashup of the other two. Therefore from a source code <br>> >>>>>> perspective it makes things a heck of a lot more complicated than <br>> >>>>>> they need to be if we simply merge things and use conditionals on <br>> >>>>>> configuration variables. For example, hyperlinks (part of grid <br>> >>>>>> services) is a really simple extension to LocalGrid services.<br>> >>>>>><br>> >>>>>> The issue of local vs remote services isn't entirely orthogonal <br>> >>>>>> either. Some parts of OGS1 use Local services -- the well know <br>> >>>>>> pattern of trying things locally first and if that doesn't work, <br>> >>>>>> proceed for a remote service call (e.g. OGS1 grid services does that).<br>> >>>>>><br>> >>>>>> I see why you want this, in abstract. If another service comes <br>> >>>>>> along, it can simply be added as a component. Or if someone writes, <br>> >>>>>> say, a completely different inventory service, its interface can be <br>> >>>>>> added as dll.<br>> >>>>>><br>> >>>>>> But in this particular case, for the code we already have, I think <br>> >>>>>> that having Local.dll, OGS1.dll and Hypergrid.dll is not working <br>> >>>>>> well, even if the configuration process is the one you suggest. The <br>> >>>>>> code is mess; things are _way_ more complicated than they need to be.<br>> >>>>>><br>> >>>>>> So, maybe, what we can do is merging these two ideas. We'll have <br>> >>>>>> only one dll (OpenSim.Region.ResourceServices.dll), but we'll <br>> >>>>>> specify things in OpenSim.ini the way that you suggest, so that if <br>> >>>>>> anyone comes along and wants to plug in a different inventory <br>> >>>>>> service, he can just specify the other dll and an entry class name <br>> >>>>>> for it.<br>> >>>>>><br>> >>>>>> What do you think?<br>> >>>>>><br>> >>>>>><br>> >>>>>>> [Security]<br>> >>>>>>> <br>> >>>>>>> SessionAuthentication = {True|False}<br>> >>>>>>> KeyAuthentication = {True|False}<br>> >>>>>>><br>> >>>>>>> ---<br>> >>>>>>> <br>> >>>>>>> The constructor is being fed a config source, so the service can <br>> >>>>>>> pick out whatever it needs.<br>> >>>>>>> <br>> >>>>>>> All the shipped grid services could move into one assembly, as <br>> >>>>>>> we're explicitly specifying the implementing calss.<br>> >>>>>>> <br>> >>>>>>> I believe this approach would get us improved flexibility.<br>> >>>>>>><br>> >>>>>>> /Stefan<br>> >>>>>> _______________________________________________<br>> >>>>>> Opensim-dev mailing list<br>> >>>>>> Opensim-dev@lists.berlios.de<br>> >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> >>>>>><br>> >>>>> _______________________________________________<br>> >>>>> Opensim-dev mailing list<br>> >>>>> Opensim-dev@lists.berlios.de<br>> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> >>>>><br>> >>>>><br>> >>>><br>> >>> _______________________________________________<br>> >>> Opensim-dev mailing list<br>> >>> Opensim-dev@lists.berlios.de<br>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> >>><br>> >>><br>> >> <br>> > _______________________________________________<br>> > Opensim-dev mailing list<br>> > Opensim-dev@lists.berlios.de<br>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> > <br>> > <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br></body>
</html>