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

[Nexii Malthus <[e-mail]>]

@Infinity Linden, that explanation was absolutely fantastic to read for a
newcomer like me to this Capability stuff. Now I understand this a lot
better. The theory behind it makes a lot of sense.

On Fri, Jun 5, 2009 at 4:57 PM, Meadhbh Siobhan
<[e-mail]>wrote;wrote:

> 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]>
> >
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>