[Opensim-dev] Cable Beach update

[Hurliman, John]

> -----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: Wednesday, January 21, 2009 9:02 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Cable Beach update
>
> Mike Mazur wrote:
>> Hi,
>>
>> I have read through the most recent Office Hour transcript[1] and Cable
>> Beach was brought up. (Thanks Nebadon!) I'm unable to attend the office
>> hours, so please allow me to contribute a little to the discussion here.
>>
>> At this stage, I don't expect Cable Beach to offer better
>> performance over the existing asset server.
>>
>> Cable Beach does offer authentication built-in, though. This allows you
>> to access your assets thorugh external (third-party) applications which
>> may be other grids, editors, websites offering items for sale, etc.
>>
>> I suggested testing Cable Beach on some regions on OSGrid to see how
>> it'll fare under real-world use. I believe Intel is currently using
>> Cable Beach on their internal grid as well as ScienceSim[2], but I
>> wanted to supplement that with some testing at OSGrid as well. Setting
>> this up sooner rather than later could help identify issues introduced
>> with needed changes, such as converting to Mono.Addins and using
>> OpenSim's HTTP server.
>>
>> I figured it's possible to run Cable Beach in parallel with the
>> current OSGrid asset server (same machine, different machine, up to
>> you), and point a few regions that get some traffic to use this
>> asset server. The asset server could use its own database (a copy of
>> the current assets
>> table?) or point at the current assets DB.
>>
>> Having said that, the end goal is to replace the existing asset server
>> with Cable Beach in OpenSim core, and end up with only one asset server.
>>
>> So as far as I understand, there are two issues with Cable Beach as- is:
>>
>> 1. ExtensionLoader
>> 2. HttpServer
>>
>> I will have a look[3] at using Mono.Addins instead of
>> ExtensionLoader in Cable Beach. We can re-evaluate this situation
>> later based on the results.
>>
>> Hopefully the upstream HttpServer can be updated as required so the
>> DLL can be updated in OpenSim. This way the asset server can use the
>> existing HTTP server.
>>
>> Any other comments or suggestions to move this forward?
>
> Just two more points from me for now
>
> 1)  Can this be put into our existing server framework (e.g. front end
> console classes derive from
> OpenSim.Framework.Servers.BaseOpenSimServer?  I know this is hardly
> the best console front-end in the world, but I would like to see us be
> as consistent as possible across all servers until something better
> comes along.
>

Certainly. You'll lose the ability to run Cable Beach as a real service, but there's no reason BaseOpenSimServer couldn't be used.

> 2)  I notice a heavy use of JSON in the client docs, which is referred
> to as the "Reference Asset Protocol".  Does this mean that such
> communication cannot be carried out using XML?   XML is what we use
> everywhere at the moment, and it would be strange to move one aspect of
> comms to JSON without any agreement to make everything JSON.
>

The "Reference Asset Protocol" refers to a mockup of the new protocol. The existing asset and inventory transactions have several assumptions baked in that are no longer true. They assume the region is fully trusted and will handle security (no longer true with open grids like OSGrid or with Hypergrid enabled regions), and that identity and authorization can both be handled with a globally shared key (no longer true with web services connecting to asset/inventory servers or direct client access).

The reference protocol is absolutely a mockup and is by no means a proposal for a final protocol. The choice of JSON over XML was arbitrary, and is one of several frontends that are enabled by default. The others are the OpenSim grid XML formats. I refer to these formats as legacy in places because they need to go away soon. XML is good, but .NET serialization is a bad way to make a standardized protocol (try writing a perl script that talks to the inventory server).

In short, additionally having the reference frontend enabled won't interfere with anything else or cause any comms to happen over JSON unless you specifically try to use it. Protocol discussion needs to happen again now that old assumptions are no longer true, but the first step is getting the infrastructure in place.

John