[Opensim-dev] Technical assessment of Cable Beach asset server

[Mike Mazur]

Hello,

Comments inline...

On Thu, 15 Jan 2009 12:19:35 -0700
"Hurliman, John" <john.hurliman at intel.com> wrote:

> > -----Original Message-----
> > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> > bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
> > Sent: Thursday, January 15, 2009 6:47 AM
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] Technical assessment of Cable Beach asset
> > server
[...]
> > 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.

All good answers. Another option is to have the asset server part of
the OpenSim source tree, but package it as a separate product when we
roll releases. This way interested parties can download it standalone
if they choose.

> > 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.

John, I didn't realize you were the author of ExtensionLoader.

I took a brief look at the region module plugin code in the region
server hoping to see how difficult it would be to convert to using
ExtensionLoader or Mono.Addins. My eyes went kinda crosseyed a few
minutes in, though that might just be because it's Friday afternoon.

I see a benefit to using ExtensionLoader because it's small and not
very complicated. Perhaps sempuki can chime in here, as he did some
work with Mono.Addins and OpenSim a few months ago, but my impression
from following his work then was the Mono.Addins was full of
undocumented gotchas and bugs.

On the other hand, with time those bugs in Mono.Addins should get
ironed out. Maybe trying to use Mono.Addins instead of ExtensionLoader
now is a worthwhile undertaking.

> > 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.

I'd appreciate if someone with more HTTP server experience could have a
closer look.

> > 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.

I'm also in favor of switching the config format from the existing XML
to Cable Beach's INI. It's much easier to grok the INI file, and it
somehow feels wrong that all the config options in the XML file are
attributes on one XML node.

Thanks for the feedback so far, guys.
Mike