[ogpx] Fwd: An Inquiry into the Nature and Causes of Web Capabilities

[Meadhbh Siobhan <[e-mail]>]

dang. i keep hitting "reply" instead of "reply to all"


---------- Forwarded message ----------
From: Meadhbh Siobhan <[e-mail]>
Date: Fri, Jun 5, 2009 at 8:56 AM
Subject: Re: [ogpx] An Inquiry into the Nature and Causes of Web Capabilities
To: Carlo Wood <[e-mail]>


ah! i see where you're going.

there is something i didn't put in the previous message.

when a capability expires and the client attempts to access it, it
should get a 404. if the system is down, the TCP connection will
eventually time out. the processing expectations for the client are
that if it needs to access an expired (or otherwise unavailable) cap,
it goes back to the seed cap and says... "hey! gimme another one of
these caps, please!"

at that point, it is up to the system hosting the seed cap to return a
cap that is accessible to the client. if the seed cap is expired, the
expectation is that the client will re-authorize (with OAuth) or
re-authenticate (with user login or transport layer identity /
authentication.)

i think this points to a philosophical difference that's plagued
protocol developers from the early days... where does the intelligence
live? in the POTS phone system, the intelligence lies with the network
and the leaf nodes are relatively dumb. tcp based networks do devolve
application layer and some network layer smarts to client.

the systems that have been deployed to date make a "network has the
smarts" assumption and current implementations don't have the feature
you're describing. personally.. i'm not a big fan of what you're
describing 'cause it increases the burden on network services (my
systems now have to have a distributed cap router and understand that
endpoints from multiple locations on the net route to a particular
system.)

but.

i'm also an experimentalist at heart. if you wanted to re-write the
caps section of the base document to describe what you're doing, and
then investigate the behavior of the two different systems under
typical failure cases (host down, host unreachable, etc.) i would love
to see if there's a major difference in behavior.

that being said, LL, PyOGP and at least one of the OpenSim
implementations have been implemented using caps as described here. so
it might be a better idea to go ahead with what we've got described
now, so we can get to the real work of describing the application
layer messages, but keep the "multi-caps" as a future expansion
option.

-cheers
-meadhbh

On Fri, Jun 5, 2009 at 8:09 AM, Carlo Wood<[e-mail]> wrote:
> Ok... but what if that host is unreachable/down for a while?
> If the hostname is a fixed part of the capability then it
> is impossible to continue.
>
> We could simply redefine things a bit, and say that a service
> returns:
>
> { range or set of hosts / the rest of the URL }
>
> Or more indetail, it could return:
>
> http://assetX-NNN.example.com/?91839838
>
> where then, as part of the protocol, the 'NNN' has
> to be replaced by by a number between 1 and N, where
> N was given to the client upon login (or whenever,
> some grid-dependent configurable value).
>
> In that case, the capability would be
> "http://assetX-NNN.example.com/?91839838"
> and thus not includes (one) host.
>
> The clients would know how to route it (they
> just fill in some number for NNN), and if that
> host is unreachable they can try another host.
>
> --
> Carlo Wood <[e-mail]>
>