Hurliman, John wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:opensim-dev-
>> [email protected]] On Behalf Of Justin Clark-Casey
>> Sent: Wednesday, January 21, 2009 9:02 AM
>> To: [email protected]
>> 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
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to