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

[Carlo Wood <[e-mail]>]

On Mon, Dec 07, 2009 at 10:30:25AM -0800, Joshua Bell wrote:
> Am I correct that this represents the previous discussion on the topic?
> 
> Carlo's post:
> 
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00363.html
> 
> Meadhbh's reply:
> 
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00362.html
> 
> Can you respond to Meadhbh's comments? Dealing with version skew is addressed
> at various levels in the protocol drafts already, from presence/absence of
> named capabilities to HTTP nuances to LLSD semantic rules. That's not to say
> that this is sufficient, but it does appear to cover a broad spectrum of
> version skew issues, so identifying those that aren't covered - or those that
> could be addressed more explicitly with numbered versions - would be extremely
> valuable.

Well, the more the protocol as-is allows corrections, improvements and
extensions later on without the need for client (coders) to know what
network/grid they are connected to, and/or what server versions are
being used, because it will all "automatically" work out, the better!

But-- it's very likely that not everything can be handled that way
and that viewers will more and more have to fall back to kludgy
heuristics to guess what new features are demanded or supported
on the current grid they connect to. I state that we CANNOT know
what changes of that type we will need in the future, I just know
that it will happen; that we'll wish that a feature negotiation
was in place from the beginning.

As a coincidence (or is it really a coincidence...) right NOW we
need this (see my other post): At the moment there is a need for
a new capability (the url for the map).

Working:

* If the client doesn't know about it, it won't ask for it (check).

* If the service doesn't know about it it won't return a capability.

Not working:

* 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).

Sure, we can make this work-- in some kludgy way or another--
requiring hardcoding special cases and "grid detection" etc.
But this is just one, or the first of many that will come,
and to deal with that is neat and controlled way, we need
protocol negotiation.

If I'm wrong, and no protocol negotiation will ever be needed,
then we will not have lost anything: the feature tables will
just stay empty and there will not be anything to negotiate.
No harm done.

-- 
Carlo Wood <[e-mail]>