[Opensim-dev] Grid Architecture, Round 3 - FIGHT!

[Sean Dague]

On Tue, Nov 13, 2007 at 08:56:31PM +0800, Adam Frisby wrote:
> Alright,
> 
> Sensible grid architecture time. After the first two rounds of 
> discussion on this, I think we can probably claim a few core decisions 
> have been made.
> 
> 1. HTTP + XML/REST seems to be the defacto standard for non-realtime 
> communications.
> 2. We use sensible standards for authentication / security - such as 
> HTTP Authentication and TLS/SSL for security.
> 3. We avoid abusing standards (ie EventQueueGet again)
> 4. We dont break it up into groups or application servers, we simply 
> enable/disable individual URIs.
> 
> 
> So, some concrete implementation ideas.
> 
> Login:
> 	simulator has URI:
> 		/users/recieve/<uuid>

What about /agents/<uuid> instead?  To make it clear that the user
server user isn't really the same kind of object as what the sim thinks
a user is.

> 	user server has URIs:
> 		/users/<uuid>
> 		/users/login (XMLRPC for the SL Client)
> 
> 	1. User engages XMLRPC login service on
> 		/users/login with their client credentials
> 	2. Login service verifies user credentials
> 	3. If successful, posts a message to their destination
> 	   and a URI for the user. Next step happens in parallel.

This seems like it should be POST /agents (in the create model shown below)?

> 	4a. Remote simulator accesses that URI to download
> 	   information about that client (other URIs,
> 	   eg inventory, etc). May POST to a URL
> 	   styled like
> 		/users/<uuid>/current_sim/
> 	   with information about the region they are in[?]

Is this Sim POSTing to User server?  Doesn't that open up a very odd
ability for multiple Sims to say "the user is here now" badly?

> 	4b. If the response from step #3 wasnt a rejection,
> 	    reply back to the login request with the IP of
> 	    the target region. (Maybe rely on it being sent
> 	    back in step 3?)
> 
> Grid Connection:
> 	grid server has URI:
> 		/regions/<uuid>/
> 		/regions/new/
> 
> 	When a simulator connects to the grid, it issues a HTTP POST
> 	against /regions/<uuid>/ or /regions/new/ with XML information
> 	like the following:
> 
> 		<request>
> 			<detail>
> 				<x>1000</x>
> 				<y>1000</y>
> 				<user>[URI]</user>
> 			</detail>
> 			...etc...
> 		</request>

Typically you'd do this as a POST to /regions/  (the new is not needed,
as POST == create)

The RESTy mapping of operations tends to go more like the following.

GET  /regions        => LIST
POST /regions        => CREATE
GET  /regions/<uuid> => GET
PUT  /regions/<uuid> => UPDATE
DELETE /regions/<uuid> => DELETE

> 	What should come back will be a identically formatted reply:
> 		<reply>
> 			<status>CONFIRMED</status>

Status should come back in the HTTP status codes

> 			<detail>
> 				<x>1005</x>
> 				<y>1004</y>
> 				<user>[URI]</user>
> 			</detail>
> 			<uris>
> 				<map>[URI]</map>
> 				<status>[URI]</status>
> 			<uris>
> 			...etc...
> 		</reply>
> 
> 	The URI's returned are addresses to services affiliated with
> 	this domain. Eg, the STATUS uri is a address for POSTing and
> 	GETting status information.

Can you be more specific on what that status is?

> 
> Handling authentication:
> 
> 	A combination of CAPS for temporary authentication (eg a list of
> 	temporary one-shot URI's that expire and reissue after use), and 	HTTP 
> authentication for permenent things (like logging into a
> 	grid) seems like a fairly sane plan.
> 
> Thoughts?
> 
> 
> Regards,
> 
> Adam
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071113/f9c9a68e/attachment-0001.pgp>