Hurliman, John wrote: > 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.
If it's going to be the default, then it really needs to be in trunk, so any core members can work on bugs in it. > >> 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. I'd really rather see us on the Addins front, and if there is something Addins is missing, lets sort that out with the community. Everyone wants to write their own plugin system, and everyone thinks everyone else's plugin system in "too heavy" for their job. Let's get over that. :) There are dozens of projects using Addins quite successfully, and if we want to get people develping drop in plugins for OpenSim, having a well understood mechanism here which people might have seen before is really useful. >> 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. My concerns in this area are that we shouldn't have 2 embedded webservers in OpenSim, as that just makes working with them hard. We should have 1, whichever makes sense. And that 1 should probably be a main project, not a branch in a seperate repository. If there are chances needed upstream, lets get them upstream instead of creating more side branches. -Sean -- Sean Dague / Neas Bade [email protected] http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
