Re: [Opensim-dev] proposal: cleanup and break up region modules
Justin Clark-Casey wrote: Dr Scofield wrote: i've been looking at where region modules live in our source tree --- OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and how they get bundled: * modules in OpenSim/Region/Modules get their own private DLL * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL off the 3 modules living in OpenSim/Region/Modules 2 might be good candidate for forge project: python and SvnSerializer. the third really belongs to the Terrain region module and seems to contain the default terrain effects. i think it would make sense to * have all region modules living in the same neighborhood (i'd prefer OpenSim/Region/Modules), the current layout is a bit confusing Don't we need to make a distinction between 'service' modules (such as the REST module) and scene/environment modules though? The former are not attached to a scene (and may well never be concerned with scene code) while the latter are very much scene related. that would be another step. first i'd like to get the modules settled in the same neighborhood. * break up the region module super-DLL so that each region module gets a DLL of its own At least on mono, I'm guessing that this would vastly expand build times. Certainly at the moment, each invocation of mono to build a new assembly appears to take far longer than building many files in a single dll. vastly? I also tend to think of the current modules in OpenSim/Region/Environment/Modules as fairly core modules that one would expect to be packaged together, and which it would be inconvenient to split up. hmm...that kind of goes against the idea of them being modules, i'd think :-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
Homer Horwitz wrote: Hi all, the current system for handling region-modules is slightly broken if you add/remove regions dynamically (or even for region-restarts). I've put up some thoughts at http://opensimulator.org/wiki/New_Region_Modules for discussion. Please answer on the associated 'discussion' page or here on the list. Nice proposal Homer. Here's another thought (to add to the pile). Is there really any point having an Initialise method at all? 1) Adam's idea of hanging the config off the scene and not passing it in via Initialise(IConfigSource) both disgusts and excites me. Disgust because it feels a bit wrong to tie Config in to Scene that closely (though maybe that's really just because Scene should be called Region). But exciting because I can imagine that we do want per region config at some point (it would be cool to be in space on one region and on Jupiter in another on the same server). Non-shared modules could still grab their config from the first scene that comes in (though having to do an if condition on the first scene will look less elegant than doing things without conditions in Initialise(). Then one could perhaps get rid of Initialise() completely and just do all initialization when the first region is added. One could almost get rid of Close() in the same way (perform close instead when the last region has been removed). Though in this case I can more easily imagine that one would want to remove all regions before adding more on the same instance (which might unnecessarily incur expensive cpu operations when initialize is called again). I'm probably just trying to be unnecessarily clever here. And I have a feeling these kinds of issues have probably already been addressed in some module system somewhere... :) 2) Is there any point on giving the Scene again in RemoveRegion? Would it be clearer just to give the region UUID instead or are there advantages to passing in Scene again? 3) On the spelling issue, I'm with MW - I think you Americans should just suck it up. I once had to work on an IBM product called WebSphere Product Center so I think that there should be some payback :) (an Init() compromise is fine though, I guess. Bring back the Empire, I say). -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] OpenSim 2nd Birthday Tommorrow - Blog About it
OpenSim's 2nd birthday is tommorrow (Jan 29th), and it would be really great if as many people as possible could put up a blog post about OpenSim tomorrow. Tell the world about your experiences with OpenSim, whatever they may be. Screen shots are always appreciated in blog posts. Once you do, please feel free to add a link to that blog post here - http://opensimulator.org/wiki/Second_Birthday in Section 4. That way everyone can see what everyone else is doing with this wonderful technology. Thanks again all for being with us through the last 2 years of amazing growth! -Sean -- Sean Dague / Neas Bade sda...@gmail.com http://dague.net signature.asc Description: OpenPGP digital signature ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] AssetBase and metadata
Hi, In Cable Beach all asset information is split over two datatypes: - the Metadata class[1] - a byte array containing the actual asset data In OpenSim we have the AssetBase class[2] which contains asset metadata and data together. I'd like to modify the AssetBase class in OpenSim so it's composed of one Metadata class. So instead of having: AssetBase ab = new AssetBase(); ab.Name = some name; ab.Description = some description; I would write: AssetBase ab = new AssetBase(); ab.Metadata.Name = some name; ab.Metadata.Description = some description; I would define the Metadata class in AssetBase.cs. The serialization and deserialization methods currently in the Metadata class may or may not be included; I see those methods belonging in the Utils class[3], perhaps. The Metadata class itself will immediately be used within the new asset server, and I can see it being useful elsewhere in the future. Should the Metadata class be renamed to AssetMetadata? Any other thoughts? Thanks, Mike [1] http://forge.opensimulator.org/gf/project/assetserver/scmsvn/?action=browsepath=%2Ftrunk%2FAssetServer%2FMetadata.csview=markup [2] http://opensimulator.org/cgi-bin/viewcvs.cgi/trunk/OpenSim/Framework/AssetBase.cs?view=markup [3] http://forge.opensimulator.org/gf/project/assetserver/scmsvn/?action=browsepath=%2Ftrunk%2FAssetServer%2FUtils.csview=markup ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
I'd be much more of a fan of having each module a seperate dll. Files are cheap too. :) And that makes it very clear to people what they are loading, and what they aren't loading. (On the fear of talking about performance prematurely) Won't that cause problems for the JIT'er? Normally access to member variables gets optimized away into a direct memory access rather than invocation of a JSR. If I recall correctly this optimization does not work for dynamically loaded assemblies. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
Tleiades wrote: I'd be much more of a fan of having each module a seperate dll. Files are cheap too. :) And that makes it very clear to people what they are loading, and what they aren't loading. (On the fear of talking about performance prematurely) Won't that cause problems for the JIT'er? Normally access to member variables gets optimized away into a direct memory access rather than invocation of a JSR. If I recall correctly this optimization does not work for dynamically loaded assemblies. well, if that's the case, then it's not working currently either :-) currently we lump all region modules into one large super DLL and load that dynamically. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
