Re: [vwrap] Definition of "Virtual World", in a protocols context

Yes, I agree with that totally Mike.

I'm glad that you pointed out that the client can be a provider of services
as well (or alternatively, services can be client-side, even if not part of
the client application).  I expect this to be a rather common use case ---
I've heard a lot of people state their interest in hosting their own
inventory and even asset services locally.

This deployment pattern could be very popular.

Morgaine.

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

On Wed, Sep 22, 2010 at 6:21 PM, Mike Dickson <mike.dickson@hp.com> wrote:

>  On 09/22/2010 10:01 AM, Morgaine wrote:
>
>> After a good night's sleep, I see that my definition still works, a minor
>> miracle.  :P
>>
>> As another indication of its robustness in the face of architectural
>> variation, I've just noticed that it applies even to virtual worlds
>> implemented as P2P.  This was more good fortune than planning, as I could
>> have accidentally mentioned servers yesterday, but didn't.  Focusing
>> entirely on the client application's role in presenting the perceptual
>> mashup has paid dividends.
>>
>> We need that kind of flexibility because our server-side architecture is
>> going to be arbitrarily complex once it is decomposed into services, so
>> tying it down in any way would probably be a mistake.  In contrast, the
>> "client application" is a single unit from a user perspective, even if
>> implemented as an arbitrary number of concurrent units in programming terms.
>>  This probably captures most scenarios that we are likely to see.
>>
>>  Well, no, the client itself could be a provider of services in a more
> distributed case.  But thats not really relevant as you suggest.   I guess
> I'm objecting to the server-side architecture comment. how the services we
> defined are implemented into a virtual world should ideally as flexible as
> possible.  The important thing to me is the service definitions (what
> messages I can send/receive) and the payload definitions/protocol used with
> the services.
>
> Mike
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>