Re: [vwrap] End point "behavior"

The "protocols perspective" on this is simply that what's behind a protocol
endpoint is a black box.  Defining a protocol on the understanding that the
endpoint will be running in some specific constrained environment is very
limiting on all other users who don't have those constraints.

In practice what I'm sure will happen is that Web technology will mature to
become as flexible and as capable as standalone technology, but we're quite
far from that ideal at present.  By the time we're finished, perhaps Web
technology will have caught up, but one should always design future systems
with a view to tomorrow's capability otherwise they'll be obsolete before
one's finished.

Morgaine.

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

On Thu, Sep 23, 2010 at 8:21 PM, Crista Lopes <lopes@ics.uci.edu> wrote:

> On 9/23/2010 11:11 AM, Meadhbh Hamrick wrote:
>
>> the great thing about standards is there are so many to choose from.
>>
>> if you want to use the asset and teleport portions of VWRAP without
>> the seed cap part, go for it.
>>
>> it's not up to the protocol designers to decide how you wish to deploy
>> your virtual world services. but clearly if you want to interoperate
>> with someone who IS using the VWRAP Service Establishment pattern,
>> you'll have to follow that draft.
>>
>> this is part of the "we define mechanism, not policy" mantra.
>>
>>
>
> This statement is true for phat clients; it is false for the web browser,
> because for the web browser some of these "standard-compliant" mechanisms
> are intrusions into policy and engineering design -- and irrelevant for
> interop, as far as I can tell. The standard, for web browsers, should be
> agnostic on these mechanisms. Putting an asset in the user's machine by
> pulling or pushing is irrelevant, each world can do it in whichever way it
> wants, and it will all work.
>
> So the drafts need to say: "if you have a client whose viewer is fixed,
> then here are the standards necessary for interop; if you have a client that
> takes the viewer dynamically, then these mechanisms are not necessary for
> interop." Or else say, right upfront: "these standards are for clients whose
> viewer is fixed; they are implementation recommendations for clients with
> dynamic viewers based on... good practices(?)"
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>