Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint)

[Suzy Deffeyes <[e-mail]>]

>
> * In the latter case (the service not knowning about it) the viewer
>  needs to fall back to the old style map on opensim and to a hardcoded
>  S3 url on Second Life (which DOES support this capability, but just
>  doesn't know about the "capability" url itself).
>
> * Once Linden Lab (or any other grid that will implement the same
>  way that map works) stops supporting the "old style map", there
>  is no way to tell the client explicit that THIS "feature" (the
>  new way of how map works) is now mandatory, other than the
>  existing method of requiring a minimal *viewer* version... which
>  of course only works for the few viewers that are supported this
>  way and which is a very crude way to state that one feature is
>  now mandatory (bound to fail once there are lots of features
>  like this to be negotiated).
>

So in the map tile case you mention, if the viewer gets a cap to the new way
of fetching tiles, it wouldn't try to do the old way.   In this particular
case, it seems like getting a cap for http fetch of map tiles deprecates
client use of the old mechanism.

"Mandatory" is something that should be dictated by a VWRAP spec version
number. So in version 1.0 the map capability is not mandatory, and when we
rev the version to 1.1, we might decide to make it mandatory. A viewer
supporting version 1.1 of the spec could reliably ditch the old code.

One thing I do ponder that might be related is how do I specify/decide that
I do *not* want to trust a specific packet type from the region. For
instance, if I get a cap for inventory operations from my agent domain, then
maybe I don't want to trust UDP packets related to Inventory that I get from
Joe's Prim Ripper region.  Will it always be obvious what the desired
behavior in the viewer is?  In the map tile example, should I blow off any
map tile packets i get from a region that also claims to support the map
tile HTTP cap?

Suzy Deffeyes/Pixel Gausman
IBM