Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision

[Morgaine <[e-mail]>]

Yes indeed, the client is just another protocol endpoint.

Notice that many alternative implementations of the SL viewer exist because
the only requirement is adherence to the protocol at the endpoint, with no
specific implementation or client structure being mandated.  This results in
great flexibility.

Also, it is common among the developer community to place a proxy in front
of the normal viewer, either to extend the client functionality with Jabber
IM support or to assist in protocol debugging.  This is possible because the
protocols do not mandate any particular client-side implementation, so the
proxy takes on the role of the client endpoint at one or more levels.

The ideal network protocol is one which is wholly independent of the
architecture behind its endpoints, at both client and server ends.  This
provides the greatest room for developing more efficient and scalable
implementations.  Given the importance of scalability in this area, I
believe we should strive to give VWRAP these well known benefits too.

Morgaine.






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

On Mon, Aug 31, 2009 at 2:15 PM, Kari Lippert <[e-mail]>wrote;wrote:

> But isn't the client just another endpoint? I didn't see that a
> distinction was being made referring only to server endpoints.
>
> Kari
>
> On Mon, Aug 31, 2009 at 9:00 AM, Carlo Wood<[e-mail]> wrote:
> > On Mon, Aug 31, 2009 at 05:27:05AM +0100, Morgaine wrote:
> >> As an alternative, I propose a simpler and much more flexible approach:
> define
> >> virtual worlds as anything that implements the required endpoints of the
> VWRAP
> >> protocol.  We do not need to know anything else about them.  This lets
> the
> >> people who actually design the virtual worlds decide what constitutes a
> virtual
> >> world.  The only thing that interests us is that these "virtual worlds"
> >> implement the VWRAP endpointst.
> >
> > Very smart :)
> >
> > I have just one side note here; if someone creates a 'D' (sorry, can't
> use
> > "virtual world" until we agree) using VWRAP internally too, again
> confusion
> > might arise about the exact boundary of that "virtual world" (it could be
> > the 'C's in that case).
> >
> > But you are very correct to realize that one aspect of a region domain
> > run by a "single administration" (could be multiple administrations that
> > work very close together: a 'D' thus) is that for all we care they use
> > a different protocol inter-world (or extensions to VWRAP). Therefore
> > you can replace my definition ("administrative boundary") very well
> > with "VWRAP endpoints", without setting demands on internally used
> > protocol.
> >
> > HOWEVER...
> >
> > the above only applies to server-server protocol, not to server-client
> > protocol: "shared experience" is of utmost importance; part of our
> > standardization efforts is in order to make it possible for viewers
> > to represent "the world"/galaxy as much as possible in a consistent
> > way to different users, which gives rize to the need of a consistent
> > client protocol!
> >
> > Therefore, VWRAP would not only describe the protocol between the
> > end-points of a virtual world ('D') but also the protocol used to
> > communicate with viewers (clients). Though, I guess you can see
> > that interface as an external boundary too.
> >
> > PS. The only way to keep wild growth at bay in the client-server protocol
> > area, where, I expect, different 'D's (virtual worlds) will add
> extensions
> > and start to release their own viewers to support those, is to add
> > support for protocol negotion in VWRAP. Without support, it will still
> > happen, but out of control, and become a total mess.
> >
> > --
> > Carlo Wood <[e-mail]>
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
>