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

[Ryan McDougall]

Executive Summary: +1 to all John's modifications -- provided he is
willing to do the integration.

On Fri, Jan 16, 2009 at 10:17 AM, Mike Mazur <mmazur at gmail.com> wrote:
> 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.

In general I find the quality of John's code to be exceptionally high,
and I found the internals of Mono.Addins to be over-engineered and of
average quality.

As others have pointed out, the main benefit of Mono.Addins is that
its maintained by someone else. If John is willing to port all my
Mono.Addins work to to ExtensionLoader, and maintain any future bugs,
then I am all for it.

+1 for ExtensionLoader

Cheers,

>> > 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
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>