Thank you for the technical assessment Mike, and for everyone's comments so far. I've added a few notes and clarifications inline.
> -----Original Message----- > From: [email protected] [mailto:opensim-dev- > [email protected]] On Behalf Of Justin Clark-Casey > Sent: Thursday, January 15, 2009 6:47 AM > To: [email protected] > Subject: Re: [Opensim-dev] Technical assessment of Cable Beach asset > server > > Mike Mazur wrote: >> Hello, >> >> I'd like to present my analysis of the Cable Beach[1] design & code, >> with the aim to eventually use it as the official OpenSim asset and >> inventory server. > > Hey Mike. Thanks very much for doing this summary. Here are some > comments. Sorry these are grouped together but I think this is better > than having them interspersed in a long e-mail. > > 1) As a general point, is Cable Beach development going to continue > externally to OpenSim? Point 3 in > http://opensimulator.org/wiki/AssetServerProposal talks about this > being an alternative to proprietary asset servers. > If development of it continues in OpenSim, doesn't it then just remain > our own flavour of asset service (albeit with a few more features and > more modularity). > This is an open question that I think is best answered by the OpenSim development community. Would OpenSim benefit the most by pulling this into trunk? Should an svn:externals property be used to keep the project in its own repository but use it as a default option? There are several approaches that can be considered. I can assist with transition and future development, but my goal is to hand this project over to the OpenSim community to be integrated in a way that makes sense. > 2) I agree with you about the plugin concerns. It would really not > be nice to see another plugin infrastructure come into the OpenSim > tree (in addition to Mono plugins and the region module plugin subsystem). > My impression was that we had agreed to an eventual migration to Mono > plugins. My understanding was that even if it's technically inferior > to home grown solutions right now, the fact that Mono addins has an > independent community (being used in various other projects such as > MonoDevelop) makes it a better long term alternative both from a > maintenance and documentation point of view (we don't have to take on > that burden ourselves) and for future functionality (independent teams > do nice things like making modules browsable/changeable via a generic > web interface). > > So I would argue that we should look to convert Cable Beach to use > mono addins if we are going to take it into core. > However, this may make it more difficult to share plugins with non > OpenSim Cable Beach instances (if any such exist). > This might be a separate thread of discussion worth having, but ExtensionLoader was written specifically to address the problems and shortcomings of Mono.Addins. The code has been frozen for months, and essentially boils down to one interface and two function calls. See this page for a couple of points on why ExtensionLoader should be used in place of Mono.Addins. http://code.google.com/p/extensionloader/ Phasing out Mono.Addins is my suggestion, but it's not a requirement. In fact, attempting to reproduce what ExtensionLoader does in Cable Beach with Mono.Addins could be enlightening. > 3) HttpServer. Do we really want to be using another http server in > addition to HttpServer.dll? This doesn't actually bother me too much > since it's hidden to the user and http is very well known, but it > might be an issue. > A clarification: Cable Beach uses HttpServer.dll as well, from the C# Webserver project. However, it's a modified version kept in a separate repository (browse the repository here: http://www.openmetaverse.org/viewvc/index.cgi/misc/HttpServer/). I'm a developer on the C# Webserver project, and weighing my options it seemed the best approach was to branch the project into a "HttpServer lite" version. All external dependencies are removed (some of them were fairly heavy), and several features have been added to bring it closer feature-wise HttpListener. Even beyond HttpListener functionality, it has support for client SSL certificates which can enable secure sim<->sim and sim<->grid communication. OpenMetaverse.Http provides full certificate chain generation so everything can happen programmatically. If OpenSim has an adversity to using the lite branch, I can commit some of the new functionality back to the HttpServer trunk. However, take a look at both versions side by side when making a decision. > 4) Config files. I seem to remember MW saying that the XML files for > grid config are actually legacy. So going to something that uses Nini > (as I believe Cable Beach does) would actually be a good thing, though > we would really want to move all the other grid configs to Nini sooner > rather than leaving everything more confusingly inconsistent. > I agree that moving away from the legacy XML files for all of the grid services is a good idea. Code can be borrowed from Cable Beach to speed up the transition. The Nini project seems to be dead; I wasn't able to contact anyone about patches. Cable Beach is currently using the modified version of Nini in ExtensionLoader that fixes a couple bugs (a problem with finalizers that was causing random debugging problems with projects using Nini, and adding the ability to read keys without values). If OpenSim wants to maintain their own version of Nini that would also work. >> [snip] John _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
