Subject: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion

From: David W Levine <[email-masked]>
Date: Tue, 27 Apr 2010 17:41:55 -0400

As always, food for thought, probably partly baked. 

Josh Linden's presentation on the Linden Legacy Protocol 
raises the possibility that a substantial number of 
operations currently managed by the Linden Labs client be
viewed as "out of scope" for VWRAP and exposed as "there is
a URI/URL which provides access to a service to perform this
task."

Thus rather than including a set of LLIDL messages which define
how to set parcel permissions, you would associate a "Here is a
URI to invoke to get to a UI about this parcel" 

I would argue this solves roughly 1/3 of the problem. It makes it very
easy for a deployed to provide a customer user interface, and it nicely
reduces the amount of work needed to describe a useful protocol. I also
said 1/3 because I think it misses two things. First, it begs the
question(s) "What cues are needed to let the client know where things
happen" and second, it misses the need to expose the attributes these
interfaces would manage in a programmatic fashion.

Effectively, the first problem is one of asking "How do we overlay the
scene graph with UI cues." The more I think about it, the more I like
the idea of solving this problem elegantly. In particular, the obvious
design "This portion of the scenegraph or this broad area of virtual
space" has "This URI" to invoke for more information seems pretty
straightforward. How to cue things like "parcel boundaries" and "Has this
property" is a little less obvious, but a good solution would be well
worth having. Notice that this also allows some potentially elegant
integration points. One could expose custom web page UIs as associated
with Vendors, Buildings, portions of the ground, or any part of the
scenegraph. 

The second problem is also one worth solving, tho its more difficult. 
I think it falls into two or three parts. The easy bit, is again, the 
"cue" issue. In short, how does one find out that there *is* structured
data or an API associated with some portion of virtual space. At one
level, the temptation is to say the web solves this already, and blend
it in with an overall scheme for associating URIs with each bit of
virtual space or virtual item. I'm not sure this is sufficient, but I
think it serves as a nice starting point. 

I think a small worked example would be helpful. This is intended to be
fairly accurate, but clearly not more than a thought experiment. 

Posit a virtual space which wishes to expose an administrative
interface which permits visitors with proper permission to change
several parameters of the physics engine. The current model of things
would require a cap and a custom bit of user interface, or user
interface exposed via some "in world" hook, such as a prim exposing a
web page, or a web page entirely disjoint from the inworld experience. 

Instead, we would provide a way for the region to advertize the
existence of the service to the client. I am, for example, imagining
either a capability exposed by the region, or a public URI/URL exposed by
the client. (Whether the approach is fully web centric, or blended in
with VWRAP style of capability access is clearly something worthy of
discussion) 

The client, on arrival to the region, fetches the URI, using content
negotiation and gets back a "cue" to display to the user that a service
is available. (Content negotiation let web based internationalization
and such simply happens) The cue is presented to the user as the client
sees fit, and if it is invoked, an associated URI launches the 
user interface web service, which can be pre-fed with context, based
on the user. 

Now, this is doubly inappropriate for a programmatic approach. We neither
want to make programs screen scrape for content cues, nor do we want to
present them with a nice pretty user interface to manipulate. Thus,
a structured data path would be desirable. More on thinking about how
regions and scenegraph can expose APIs for performing tasks in a future 
post

- David
~ Zha

---

From: Lawson English <[email-masked]>
Date: Tue, 27 Apr 2010 15:23:28 -0700

David W Levine wrote:
> [...]
> regions and scenegraph can expose APIs for performing tasks in a 
> future post

Goes back to the AppleEvents/AppleScript model of having predefined 
suites of actions (programming-actions as well as user, in this case), 
plus the ability to provide "dictionaries" for custom actions and 
parameters that they accept. There's plenty of available models for how 
this could work (at a less user-oriented manner) in languages with  
introspection. We just need to adopt a plain-text variant (no hash codes 
and such).

Lawson

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 28 Apr 2010 09:39:06 -0600

Does the method for exposing an API need to be different from the method that exposes a user interface?

John

On Apr 27, 2010, at 2:42 PM, "David W Levine" <[email-masked]<mailto:[email-masked]>> wrote:

regions and scenegraph can expose APIs for performing tasks in a future post

- David
~ Zha

---

From: Richard Newhook <[email-masked]>
Date: Wed, 28 Apr 2010 12:05:05 -0400

post

   I'd like to add some extra detail here to help explain the weaknesses to
using this approach a little more.  While it's tempting to feel that a
prepackaged UI component would eliminate a significant portion of
complexity, it makes some strong assumptions about the circumstances under
which it will be applied: capabilities of the consuming endpoint,
representational restrictions, etc.  The effect of each assumption that we
add is that we become more tightly tied to that exact situation described
by the assumptions, and more burdensome to those situations outside the
assumptions in order to integrate with us.

    One of the assumptions of the prepackaged UI approach that carries a
heavy burden is that the consumer of the service is a human.  Ultimately
that may be true, but the human part of the whole system is little more
than the tip of the proverbial iceberg.  If you look at most virtual
worlds, the human-to-computer interface (a.k.a "the client") is only a
small portion of the total infrastructure.  The rest consists largely of
back-end services and systems that keep the world 'turning'.  For example
(the quintessential SL world), there's presence services, money
transactions services, region simulators, message routing, backup services,
network monitoring....and untold many more.  These are the major consumers
of VW data, and practically none of them will benefit from a prepackaged UI
component.  If anything, the burden of having to untangle the data from the
UI will be a significant impairment to these services.

   The prepackaged UI component itself poses some assumptions that are,
quite frankly, unreliable at best.  It is conceivable that some
implementations of virtual worlds may not have a standard HTML rendering
component.  For example, mobile devices with extremely constrained display
sizes.  Or virtual worlds targeting the blind.  Or systems that act on
behalf of the user in a semi-autonomous fashion.  In other words, we'll end
up restricting the usefulness to a very specific set of circumstances, or
eventually see it mutating into a monster in the attempt of making it
useful to all circumstances.

   It'll also break the immersiveness/cohesiveness of third-party client
implementations, or it will affect the look/feel (think: other VW's logo
embedded in your own client), or it'll introduce a new security attack
vector into the client, etc etc etc.  You get the point.

   Perhaps, then, what we would do is approach the issue from a different
angle, one that permits the assumptions to be optional.

   For example, each service would provide the following:
   1) A definition of the service call, describing the methods, fields and
validation rules required.  Some of this is already in common use, via XML,
DTD.
   2) The service itself to perform the actions.  For example, SOAP or WSDL
services, JSON-based calls, etc.
   3) A working implementation of the service in HTML form (the
prior-mentioned UI component) that can be displayed and used directly.  Can
also be used as a living example of how to make use of 1) and 2) in a
functional implementation.

   This type of approach would both give an easy-out escape for those
clients that do not wish to deal with the messy details of the service,
while still accommodating those clients that have a need to get down in the
weeds of the service.

   Thoughts?

   Richard/
   Newfie Pendragon (SL)

---

From: David W Levine <[email-masked]>
Date: Wed, 28 Apr 2010 12:14:11 -0400

"Hurliman, John" <[email-masked]> wrote on 04/28/2010 11:39:06 
AM:

> [image removed] 
> 
> Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol 
discussion
> Hurliman, John 
> to:
> David W Levine
> 04/28/2010 11:40 AM
> Cc:
> "[email-masked]"

I've been giving that exact question some serious thought. One simple
answer is to say, as we often do, "Content Negotiation Saves the day!"
If you want the programatic api, ask for application/xml, if you want 
something to present to the user, ask for text/html. If one wants to be
stronger, make the mime types more explicit. (I'm not thrilled with this
because if we can reuse existing, obvious mime types, I tend to think
its much better) 

But.. there are at least two things which make me go "maybe not." Part
one is, well, contextual. Do we expose things primarily as part of the
visual client centric scenegraph? If we tie things to closely to be
"logged in" to a region and having a client, then we end up making it
much harder for applications (and for that matter clients) which are
substantially different than the current client. We get a lot of power
by saying "This service/ui/api" is associated with "this portion of the
scenegraph." in terms of the immersive user experience. But.. the same
power gets in the way of web service like integration where one might well
want to simply expose a URI that lets you directly manipulate things in
a portion of the world. 

My current rough thinking is that if we do things correctly, we can expose
the same API via both "web external" facing discovery and 
"scenegraph internal" facing discovery. If we let the UI/API be chosen
by content negotiation, we may be done. (Tho, I'm not at all user exposing
a UI will help much, as you'll likely not have enough context to do 
anything
useful with it, but.. I can imagine clients which will) 

As I said. Very much partly baked thinking at the moment, ripe for 
discussion.

- David
~ Zha

> Josh Linden's presentation on the Linden Legacy Protocol
[snip]

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 28 Apr 2010 16:07:16 -0700

> As I said. Very much partly baked thinking at the moment, ripe for 

I looked around for a dictionary of resources for VWRAP, and it looks 
like there isn't a specific set given as the time of the e-mail. I read 
over the VWRAP docs and seen the pattern to follow. I heard there are 
some implementations, yet those implementations haven't really exposed a 
given set beyond the sources that already reveal the older OGPX 
implementation.

I looked for the VWRAP resource dictionary in order to align SNOW-375 
resources where ever they overlap. So far, SNOW-375 has these: 
https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources

There is more in SNOW-375 for full duplex, but that set represents some 
of the common client/server requests.

If there is a dictionary that has already been negotiated that doesn't 
assume the client is a single end-point, I would like to know of this so 
we can work on this together.

As you can see from this pic, I do speak of SNOW-375 as a working 
example: http://twitpic.com/1gl71s

Notice the viewer/render/scenegraph is one window and the rest of the UI 
is each in their own window. These are separate programs, so there is 
more than one end-point on the client-side.

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 28 Apr 2010 18:07:40 -0600

> -----Original Message-----
> From: Dzonatas Sol [mailto:[email-masked]]
> Sent: Wednesday, April 28, 2010 4:07 PM
> To: David W Levine
> Cc: Hurliman, John; [email-masked]
> Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy 
> Protocol discussion
> 
> David W Levine wrote:
>> 
> like there isn't a specific set given as the time of the e-mail. I
> read over the VWRAP docs and seen the pattern to follow. I heard there
> are some implementations, yet those implementations haven't really
> exposed a given set beyond the sources that already reveal the older
> OGPX implementation.
> 
> There is more in SNOW-375 for full duplex, but that set represents
> some of the common client/server requests.
> 
> assume the client is a single end-point, I would like to know of this
> so we can work on this together.
> 
> Notice the viewer/render/scenegraph is one window and the rest of the
> UI is each in their own window. These are separate programs, so there
> is more than one end-point on the client-side.
> 
> 

No, there is no dictionary of resources defined in the VWRAP spec so far. Although I haven't seen a roadmap for VWRAP yet, my current understanding is something like this:

1. Agree on common low level protocols
 a. Common types
 b. Common serializations
 c. Common transports
2. Define a system for requesting and consuming resources
 a. Defining resource providers and consumers
 b. Authorization/authentication
 c. Service and content negotiation
3. Defining service endpoints
 a. Categorize each set of service requirements, determine what needs API-level standardization and what is treated as an "opaque" endpoint
 b. Standardize one of the special service requirements
 c. Repeat b. until someone declares the current effort "done"
 d. Repeat b. as unofficial extensions that aim to influence VWRAP2

Where we don’t start to see a meaningful list of RFC-referenced or commonly used service endpoints and the draft protocols for those until around 3b, and we're more or less finishing 1c and starting discussion on 2a right now (with some open ended discussion looking forward thrown in). This isn't an official roadmap or inside knowledge, just my personal observation from the I-Ds, IETF gatherings, virtual meetings, and mailing list discussions. If anyone has a deeper or more clear insight into what we're doing please correct my roadmap.

John

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 28 Apr 2010 17:37:25 -0700

so i feel your pain, david.

but i want to ask, must the protocol specify ALL possible interfaces? isn't
it possible for the VWRAP suite of protocols to specify a set of interfaces
and resources for a bare minimum and leave the rest to implementers?

in other words... i think we can get some radical agreement that
authentication and teleportation and so forth are important to all virtual
worlds. but we might have some argument that game script and land ownership
interfaces are universally important.

maybe it's enough in this working group to define the basics and have other
features be proprietary extensions?

this is one of the features of the OMG process i liked; people could extend
"CORBA" all they wanted, but if they wanted their extensions to be part of
the spec, they had to spend a few days in hotel bars lobbying other members
to not object when it's discussed in the orbos meetings.

in other words... would it kill us if we moved forward with what we seem to
have agreed to in the chartering process, let people try several different
solutions for annotation of objects in the virtual world, write a bunch of
competing drafts, then retire to the hotel bar for a few days and come out
with an agreement for how we handle different "extensions"?

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <[email-masked]> wrote:

> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

---

From: John Hurliman <[email-masked]>
Date: Wed, 28 Apr 2010 17:59:31 -0700

+1 to moving forward with a bare minimum set of requirements. The trap I 
want to avoid is getting rough consensus that there are a ten different 
areas where we need to standardize communication, but when it comes time 
to actually doing the standards work it turns out only five of those 
areas are relevant to the active participants. The other five areas 
receive a fair dose of idle speculation, but otherwise go nowhere and 
stall the overall process.

If anyone identifies a specific resource (service endpoint, set of 
endpoints, suite of bi-directional events, whatever) that they want to 
see standardized, I would prefer to see it drafted / prototyped / alpha 
tested before arguing that it should be officially sanctioned by VWRAP.

John

On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote:
> but i want to ask, must the protocol specify ALL possible interfaces?
> isn't it possible for the VWRAP suite of protocols to specify a set of
> interfaces and resources for a bare minimum and leave the rest to
> implementers?
>
> authentication and teleportation and so forth are important to all
> virtual worlds. but we might have some argument that game script and
> land ownership interfaces are universally important.
>
> maybe it's enough in this working group to define the basics and have
> other features be proprietary extensions?
>
> this is one of the features of the OMG process i liked; people could
> extend "CORBA" all they wanted, but if they wanted their extensions to
> be part of the spec, they had to spend a few days in hotel bars lobbying
> other members to not object when it's discussed in the orbos meetings.
>
> in other words... would it kill us if we moved forward with what we seem
> to have agreed to in the chartering process, let people try several
> different solutions for annotation of objects in the virtual world,
> write a bunch of competing drafts, then retire to the hotel bar for a
> few days and come out with an agreement for how we handle different
> "extensions"?
>
> -cheers
> -meadhbh
> --
> <mailto:[email-masked]>
>
>
> On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 28 Apr 2010 22:04:21 -0700

this is part of the reason we wanted to break stuff up in to different
documents. say all the docs we propose become RFCs, deployers could choose
to implement some, but not all of the RFCs. eventually if we want VWRAP to
advance to the "real" standard stage, you have to demonstrate at least two
genetically distinct implementations.

so as we move forward, if it turns out that we lose interest in half the
specs, they can wither and die without affecting the others. or at least
that was the idea.

and i think barry and josh can comment on this a little more
authoritatively, but my understanding is that if, as a group, we decide to
add a new document to the charter, it's not _that_ difficult to do. removing
documents is a little harder, but not completely impossible.

-cheers
-meadhbh

On Wed, Apr 28, 2010 at 5:59 PM, John Hurliman <[email-masked]>wrote:

> areas where we need to standardize communication, but when it comes time to
> actually doing the standards work it turns out only five of those areas are
> relevant to the active participants. The other five areas receive a fair
> dose of idle speculation, but otherwise go nowhere and stall the overall
> process.
>
> endpoints, suite of bi-directional events, whatever) that they want to see
> standardized, I would prefer to see it drafted / prototyped / alpha tested
> before arguing that it should be officially sanctioned by VWRAP.
>
> John
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 29 Apr 2010 14:08:15 +0100

I'm glad to see Dzonatas bring this topic to the fore.

When designing a software system or a protocol in the REST architectural
style, the task of problem analysis is first and foremost concerned with
splitting the problem space into REST resources or nouns.  This is as
central to REST as analyzing a problem into classes and objects is in
Object-Oriented design.

Unless you know what your nouns are, you don't actually have anything
concrete to talk about (in the REST sense).  I've been trying to get a list
of REST nouns out of OGP designers since the beginning of the AWG effort,
and the response has always been that "it's coming shortly".  It is a puzzle
to me why it never materialized.

If in VWRAP we are choosing to stick with REST, then I suggest that we had
better populate our noun-space rather quickly, because a REST-based protocol
is best defined as the messaging that operates a state machine over the
states of its REST nouns.

Morgaine.

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

On Thu, Apr 29, 2010 at 1:07 AM, Hurliman, John <[email-masked]>wrote:

> No, there is no dictionary of resources defined in the VWRAP spec so far.
> Although I haven't seen a roadmap for VWRAP yet, my current understanding is
> something like this:
>
>  a. Categorize each set of service requirements, determine what needs
> API-level standardization and what is treated as an "opaque" endpoint
> Where we don’t start to see a meaningful list of RFC-referenced or commonly
> used service endpoints and the draft protocols for those until around 3b,
> and we're more or less finishing 1c and starting discussion on 2a right now
> (with some open ended discussion looking forward thrown in). This isn't an
> official roadmap or inside knowledge, just my personal observation from the
> I-Ds, IETF gatherings, virtual meetings, and mailing list discussions. If
> anyone has a deeper or more clear insight into what we're doing please
> correct my roadmap.
>
> John

---

From: David W Levine <[email-masked]>
Date: Thu, 29 Apr 2010 10:48:03 -0400

Its interesting.  I took Josh's presentation as part of an attempt to look 
at how we
avoid having to specify a ton of stuff when we get to the next round of 
effort, and
very much an attempt to stir some thought. In particular, Josh's proposed 
approach
is very much an effort to keep VWRAP *out* of the business of specifying 
stuff
it doesn't need to specify. 

That said at the "Lets talk about how we might approach problems" level, 
it raised some
interesting questions. Questions I think need some love at the "Does this 
provide a framework
which would let us totally avoid a TON of work in the mainline of the 
workgroup" level. 

The WHOLE point of Josh's proposal and my comments on it is to see if we 
can define
a simple model so that implementers of virtual space services (regions) 
can expose
proprietary extensions in a way which cues the consumer, and gets the 
protocol out of the way. 

I think its not only enough for the group to define the basics, but the 
only way forward. But, that
actually means looking at patterns like "how do I associate my private 
service with
part of the scene I am serving"  The example I gave was explicitly 
described as "so how might
this work" not "We should specify this." 

I think we can start to work out how regions ought to work in parallel 
with updating the base
getting teleport published and merging in the content we've all agreed 
needs merging. The
presentation Josh produced on the legacy protocols is at a high level of 
lets start
thinking about this, as was my response. The ideal out come of that would 
be a
"Yes, this could work"or "Oh, no, it misses these three things, lets see 
how that would work"
as input into describing a very concrete, small set of building blocks 
which would allow
regions to standup proprietary services with web style user interfaces 
hosted by those
services (Nicely requiring zero work from VWRAP) and possibly, also 
showing how
to permit API style services to follow the same path. 

- David
~ Zha

discussion
> Meadhbh Hamrick 
> 04/28/2010 08:42 PM
> vwrap
> but i want to ask, must the protocol specify ALL possible 
> interfaces? isn't it possible for the VWRAP suite of protocols to 
> specify a set of interfaces and resources for a bare minimum and 
> leave the rest to implementers?
> 
> maybe it's enough in this working group to define the basics and 
> have other features be proprietary extensions?
> 
> extend "CORBA" all they wanted, but if they wanted their extensions 
> to be part of the spec, they had to spend a few days in hotel bars 
> lobbying other members to not object when it's discussed in the 
> orbos meetings.
> 
> in other words... would it kill us if we moved forward with what we 
> seem to have agreed to in the chartering process, let people try 
> several different solutions for annotation of objects in the virtual
> world, write a bunch of competing drafts, then retire to the hotel 
> bar for a few days and come out with an agreement for how we handle 
> different "extensions"?
> 
> -cheers
> -meadhbh
> --

post

---

From: Morgaine <[email-masked]>
Date: Thu, 29 Apr 2010 18:45:17 +0100

I suspect that everyone would agree that we should find the smallest set of
protocol requirements that covers the primary use cases effectively.  There
is of course a proviso implied there --- less common use cases must still be
possible. Our protocol framework must be flexible and extensible enough to
allow that.

Ever since David gave us his document on the deployment patterns that are
possible when services are decoupled, I think we have been charting a steady
course through fairly calm waters, because we haven't needed to pick and
choose deployments.  Instead, our VWRAP protocol need only provide the *glue
* to link decoupled services together, thus allowing a wide range of
deployments to be chosen by individual VW service providers.

That view provides a structural target for us:  to make the VWRAP protocol
an effective glue for services, in the same sense as the Unix shell is an
effective glue for binding together Unix programs into multi-part
applications.  In our case, the protocol will bind together services to
create a system of interoperating worlds.

What we should do therefore is to enumerate the primary use cases consistent
with our agreed charter, and to find the smallest amount of protocol glue
that satisfies those requirements (and the charter), without cutting off
other use cases.

Different people will of course champion different use cases in accordance
with their interests, which is perfectly fine and to be expected.  The
protocol needs to cover those particular use cases *well*.  If our protocol
is not flexible enough to cover even the WG's members' core deployments then
it certainly won't be flexible enough to allow for less common use cases,
and we will have failed.

The core deployment patterns of most interest to me are those that allow
tourism among multiple virtual worlds (the major use case for open worlds
interop), so of course I will continue to champion those use cases.  At the
other end of the spectrum we have "walled garden" deployments, and others in
between.  As long as we ensure that services are fully decoupled, and as
long as singletons are avoided (eg. for asset storage), we should not have a
major problem in achieving this spectrum of goals within a very concise
protocol.

That said, the above is not enough.

I agree with David entirely that a fundamental part of the interop problem
concerns associating components of the perceived VW experience with
services, programmatically.  It is not enough merely to specify services.
Clients have to be able to combine them programmatically to create the
composite 3D audio/visual/textual mashup.  If we don't provide a way of
doing this then we have failed to deliver a protocol for interop.

So let's find our core requirements based on our core use cases, and let's
find a small but powerful mechanism that allows services to be combined in
creating the VW mashup for interop, and we will have succeeded.

Morgaine.

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

---

From: Bill Windwalker <[email-masked]>
Date: Fri, 30 Apr 2010 05:23:13 -0700 (PDT)

I am all for the Legacy Protocol as long as the Legacy Protocol will not hold linden lab back for it starting to look like there is a great need for more then one type of Viewer made by Linden Lab.
For holding on to buggy whip in side a race car is not needed and thats how some of Legacy software works.
First what will it cost later on ?
will it hold the company back?
how many people wil use it?
are there not other steps to be taken ?

________________________________
From: Morgaine <[email-masked]>
To: [email-masked]
Sent: Thu, April 29, 2010 1:45:17 PM
Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion

I suspect that everyone would agree that we should find the smallest set of protocol requirements that covers the primary use cases effectively.  There is of course a proviso implied there --- less common use cases must still be possible. Our protocol framework must be flexible and extensible enough to allow that.

Ever since David gave us his document on the deployment patterns that are possible when services are decoupled, I think we have been charting a steady course through fairly calm waters, because we haven't needed to pick and choose deployments.  Instead, our VWRAP protocol need only provide the glue to link decoupled services together, thus allowing a wide range of deployments to be chosen by individual VW service providers.

That view provides a structural target for us:  to make the VWRAP protocol an effective glue for services, in the same sense as the Unix shell is an effective glue for binding together Unix programs into multi-part applications.  In our case, the protocol will bind together services to create a system of interoperating worlds.

What we should do therefore is to enumerate the primary use cases consistent with our agreed charter, and to find the smallest amount of protocol glue that satisfies those requirements (and the charter), without cutting off other use cases.

Different people will of course champion different use cases in accordance with their interests, which is perfectly fine and to be expected.  The protocol needs to cover those particular use cases well.  If our protocol is not flexible enough to cover even the WG's members' core deployments then it certainly won't be flexible enough to allow for less common use cases, and we will have failed.

The core deployment patterns of most interest to me are those that allow tourism among multiple virtual worlds (the major use case for open worlds interop), so of course I will continue to champion those use cases.  At the other end of the spectrum we have "walled garden" deployments, and others in between.  As long as we ensure that services are fully decoupled, and as long as singletons are avoided (eg. for asset storage), we should not have a major problem in achieving this spectrum of goals within a very concise protocol.

I agree with David entirely that a fundamental part of the interop problem concerns associating components of the perceived VW experience with services, programmatically.  It is not enough merely to specify services.  Clients have to be able to combine them programmatically to create the composite 3D audio/visual/textual mashup.  If we don't provide a way of doing this then we have failed to deliver a protocol for interop.

So let's find our core requirements based on our core use cases, and let's find a small but powerful mechanism that allows services to be combined in creating the VW mashup for interop, and we will have succeeded.

Morgaine.

On Thu, Apr 29, 2010 at 1:59 AM, John Hurliman <[email-masked]> wrote:

+1 to moving forward with a bare minimum set of requirements. The trap I want to avoid is getting rough consensus that there are a ten different areas where we need to standardize communication, but when it comes time to actually doing the standards work it turns out only five of those areas are relevant to the active participants. The other five areas receive a fair dose of idle speculation, but otherwise go nowhere and stall the overall process.
>
>If anyone identifies a specific resource (service endpoint, set of endpoints, suite of bi-directional events, whatever) that they want to see standardized, I would prefer to see it drafted / prototyped / alpha tested before arguing that it should be officially sanctioned by VWRAP.
>
>John 
>
>