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

[Adam Frisby]

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>
	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.
	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[?]
	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>

	What should come back will be a identically formatted reply:
		<reply>
			<status>CONFIRMED</status>
			<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.

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