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

[Morgaine <[e-mail]>]

VWRAP version numbers should change only when the base protocol itself is
incompatible between versions, and never just because a particular feature
is or is not supported by the client or by the server.  There will be
hundreds or thousands of features in the future of VWRAP, an ever-evolving
set of them, and the protocol needs to be generic enough to support such
diversity.  Protocol version numbers are the wrong place for selecting
features or feature sets.

The map tile access mechanism is definitely not the kind of thing that VWRAP
version numbers would be expected to select.  Such a choice needs to be
dynamic because it's not fixed for the life of the session.

Maps are determined by region policy or virtual world policy, and are not in
any way related to the session that commences with authenticating with the
agent domain.  The topological layout of regions or region domains is a
matter for each virtual world to control, while the visual data for each
tile is a matter for each region or region domain to determine.
Capabilities for map retrieval will have to be obtained accordingly, in a
dynamic manner, because the mechanism that is required will vary as one
travels around.  There will probably be several mechanisms in common use.

It should be noted that VWRAP users will be visiting many different worlds,
each one with its own feature set, so non-uniformity should be expected to
be the norm.  Even our first two sample points of SL and OSgrid already
illustrate lack of uniformity in numerous features, and we can expect this
to continue and to expand.  It's a situation that we must embrace through
designing a protocol that is inherently extensible, and in which features
are selected dynamically.

Morgaine.






==========================================

On Mon, Dec 7, 2009 at 11:40 PM, Suzy Deffeyes <[e-mail]> wrote:

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