Re: [mmox] My reading of draft-lentczner-ogp-base-00

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

On Mar 13, 2009, at 12:16 PM, Latha Serevi wrote:

>
> Commentary on section 2.  The word "events" seems to be shorthand
> for "resource invocations that the entity wants performed on the  
> viewer".
> The viewer is a particular kind of protocol endpoint.  I don't see why
> this mechanism shouldn't be defined between more general endpoints.
> Overall, though, this all seems fairly straightforward and  
> potentially useful.

yup. this is intended to be used when any two endpoints wanna send  
event notifications. endpoints can be servers, proxies or clients. if  
you're reading it to mean "events" only apply to server -> client  
communications, maybe we need to tighten up the verbiage to make it  
clear.

> Summary of section 1, which tries to define the overall
> structure of the OGP protocol.   Section 1 loosely
> defines the terms:  viewer; agent;  virtual world; region.
> It introduces the entities "region domain" and "agent domain".
> It states that the "basic flow of the protocol" is for a human to
> use a viewer to instantiate an agent (via an agent domain)  in
> a region (via a region domain), thereby setting up an interaction
> where the viewer is streamed object updates from the (authoritative)
> region, and the region is streamed avatar update requests from the  
> viewer.
>
> Commentary on section 1.   It seems as though the most common
> OGP use case is being defined as the required structure of the  
> protocol.
> Is it really required that there MUST be a human in the loop?  The  
> region
> is always authoritative?  Requests from the human to the region must
> go via the agent domain?
>
> I think there's a strong need for such motivating use cases, but I  
> think
> the author shoots himself in the foot by putting it in the first  
> chapter
> of the document to which every compliant implementation MUST conform.
> Instead, I'd like to see this document use more general definitions  
> and
> relate them to use cases defined elsewhere.

good feedback. i think the way i would put it is, "our primary use  
case involves humans, but there's no requirement that a human be  
involved." in other words, if we have a solution that works for the  
"non-human" use case but not for the "human" use case, then the  
solution would be (from our perspective) less desirable than a  
solution that works equally well in both human and non-human use cases.

  that being said... some virtual worlds may view bots as a violation  
of their terms of service, but there's a wide range of applications  
that don't involve a human controlling an avatar in a virtual world.  
so from a protocol perspective, we shouldn't imply that non-human  
client applications are verboten.

during the PyOGP development, a lot of us referred to the thing we  
used to call the viewer as the "client application." i wonder if it's  
appropriate to do a search and replace on "viewer" for "client  
application" and then add a section describing the explicit viewer use  
case.