[Opensim-dev] Cable Beach update

[Justin Clark-Casey]

Hurliman, John 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: 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.
> 

Thanks.  I think someone did say on the mailing list that they were running (or perhaps it was looking to run) the 
existing UGAIM code as services, but I really don't know too much about how this works under Windows.  But even if this 
isn't true then  I would vote for consistency over functionality (without a firm agreement/intention to change the user 
interface to all the other services).

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

I agree, and we're pretty much moving away from using .NET serialization for any comms now (as shown by Diva's RestComms 
initiaitive).

Thanks for the clarifications, John.

-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com