Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures)

[Lawson English <[e-mail]>]

Thanks Morgaine. The concept of a plugin-driven client is simply your 
modular client idea built off of the existing LL client.

The final extension of your client is a collection of interacting 
plugins with a central mediator and possibly  connections between 
plugins and/or services that bypass the mediator. So the network looks 
like a star network of plugins with a central mediator and a conduit of 
connections between plugins and services. The final design would make 
the mediator an optional central point to establish new connections, and 
process scripting/macro/GUI commands, while the actual functions are 
carried out by the outlying modules, which may not even be on the same 
computer. Similarly, the "server" side might be equally as distributed 
and the distinction between client and server disappears completely with 
clients handling some 3D element generation and physics and assets, etc, 
while the server broadcasts 2D mashups of the client's perspective to 
cell phones.

Etc.

So at one end, we have pure client-server designs like Second Life, at 
the other extreme, purely p2p worlds like Croquet, and every possible 
combination/permutation in-between.

Lawson



Morgaine wrote:
> I agree with Lawson, but the topic goes far beyond gestures, so this 
> is a new thread.
>
> Putting it another way, the days of the monolithic client are over, in 
> the same way as the days of the walled garden and single service 
> provider are over.
>
> In VWRAP, we are formalizing the unbundling of service provision so 
> that server-side is becoming distributed, but we don't seem to have 
> grasped the corresponding concept of non-monolithic clients yet.  
> Perhaps the client needs more flexibility than we are currently 
> considering.
>
> Although we are not dealing with client application architecture here, 
> we /are/ dealing with protocol endpoint architecture, and the design 
> of clients has a direct impact on that.  The protocol should not 
> require nor give preference to any one particular client architecture, 
> in the same way as we seek not to hardwire any single choice of 
> server-side deployment pattern.  It seems reasonable to apply this 
> same philosophy to the client endpoint, so that the protocol can allow 
> for many different kinds of client-side deployment.
>
> Midway through the two years of operation of the Architecture Working 
> Group in SL, we explored a variety of client-side scenarios, including 
> this design for a multi-process client 
> <https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft> 
> .  This split out all functional parts of a client into separate 
> processes, all interconnected through a "Mediator" hub process via 
> sockets, while also accepting point-to-point and shared-memory 
> communication paths as accelerators between subprocesses where 
> required for speed.
>
> Such a client architecture is a perfect match for this new age of 
> multicore, among a huge list of other benefits enumerated on that 
> page.  It can be considered the fully distributed end of the large 
> spectrum of possible clients.  Lawson's SL client- Squeak bridge 
> represents another split, libomv's gridproxy 
> <http://lib.openmetaverse.org/wiki/SLProxy> and its Jabber plugin 
> <http://forge.opensimulator.org/gf/project/jabberimproxy/> shows 
> another, while LL's own system for media plugins is yet another.  All 
> these moves take us away from the notion of a VW client being a 
> monolithic entity, and correspondingly, we should no longer assume 
> that the client-side protocol endpoint is monolithic either.
>
> To that end, it might be an effective approach to model VWRAP as a 
> /protocol over sets of sources and sinks for data/.  One set is 
> server-side, which we are already modelling as a multiplicity of 
> service endpoints, and another set is client-side, representing the 
> many subsystems that deal with different aspects of interacting with 
> VW worlds and talking to their services.  Those subsystems are clear 
> candidates for distinct protocol endpoints of their own.
>
> Such a model would more accurately reflect how client applications are 
> actually built (in other words, in a modular fashion), instead of 
> funneling everything through a single client-side endpoint.  The 
> current single-client-endpoint approach is hardwiring an unnecessary 
> bottleneck into the client model, as well as encouraging a poor design 
> for clients through making all data appear at a single doorway.
>
> Perhaps we need to reflect on this a little before rushing ahead with 
> yesterday's design philosophy for protocol endpoints.
>
>
> Morgaine.
>
>
>
>
>
> =================================
>
> On Sat, Dec 5, 2009 at 2:00 PM, Lawson English <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     All this goes back to what I just posted on the SLDEV list about
>     taking initiative and coding something up. Having the ability for
>     clients to talk to each other rather than some 3rd party service
>     might blur the line concerning what VWRAP is supposed to be
>     talking about, but, IMHO, the line is getting blurred anyway.
>
>     What's the difference between a plugin sitting on someone's
>     desktop in order to augment the client in some way, and a plugin
>     that actually allows clients to talk to each other directly in
>     order to collectively augment them in some way? As far as I'm
>     concerned, these discussions about clients talking to each other
>     are just extensions totalks about what responsibilities client
>     plugins might have.
>
>     My current project is based on this idea:
>
>     http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin
>
>     I'm writing a SL client- squeak bridge (starting off easy with a
>     port of my  do-nothing Python client for practice) that will allow
>     me to test new client plugin ideas. The Holy Grail for the project
>     will be to integrate Cobalt/Croquet with SL in some way(s) and
>     that is just the tip of an iceberg that is being held under water
>     by a large outcropping of land. There's more potential in
>     P2P-VWRAP hybrids than there is in  P2P (Croquet/Cobalt) OR VWRAP
>     (clear-cut client-server worlds) taken separately. While
>     VWRAP/OGP/whatever's charter may not consider the P2P approach as
>     relevant, the fact is, P2P is potentially in ANY extension of
>     services involving clients which aren't talking exclusively to an
>     old school SL simulator.
>
>
>     Lawson
>
>
>
>
>     Carlo Wood wrote:
>
>         On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote:
>          
>
>             With all due respect,  Carlo, I am finding that I disagree
>             with your analysis.
>                
>
>
>         There is no analysis.. it is something has been said before
>         on the list: if YOU don't want something, then that doesn't
>         mean there will be no need for it in the future by others.
>
>         You shouldn't take YOUR experience and desires and then say:
>         "we will never need this, NOBODY will EVER need this",
>         while it's relatively easy and simple to add the *support*
>         for it to the protocol!
>
>         By adding the *possibility* for viewers to wait for others,
>         you do not force anyone to do it different from what you
>         describe. But you also don't take away the possibility to
>         do it how other people WANT it (like me, I personally think
>         this is important - so thus far we have a 50% - 50% vote for
>         the NEED of this wait feature).
>
>         So, to be really undiplomatic blunt: who are you to deny
>         me this experience? While adding just a little to the protocol
>         we BOTH can be happy? You can do it your way, and I can do it
>         my way? But you say: "You don't need it" and want to remove
>         the possibility from the protocol so that you can do it your
>         way and I CANNOT do it the way I want ?!
>
>         THAT is the reasoning behind NOT leaving out rather trivial
>         options to the protocol. And really, this has been said on
>         the list before a few times imho (and no, I'm not going to
>         find that back).
>
>          
>
>             I have a lot of practical experience in SL getting animations
>             as well as sound and textures to synchronize under a lot
>             of different conditions by taking into account the
>             client's existing
>             cacheing behavior.   I'm drawing on that experience for my
>             assertions.
>                
>
>
>         I am too, and I say I need this.
>
>          
>
>             I can't think of a single reasonable use case that would
>             *require* clients
>             to hold for the slowest link.  The examples you have suggested
>                
>
>
>         I can.
>
>          
>
>             don't require it to achieve the outcome you desire.    
>
>
>         ??? Then you didn't read very well what I said.
>         If you want to do what I said then you *NEED* the possibility
>         to wait
>         for other (some) clients (some limited time), and why not,
>         have the
>         possibility to abort, or continue anyway (as you want).
>
>         Having those options you can synchronize the experience well
>         within
>         lag-time, well within typing-delay time (ie, under 1 second).
>         If you
>         don't wait, the playing time could run up till 30 seconds or more!
>
>         Having those options you can synchronize the experience well
>         within
>         1 second AND you can do what you want: just state don't wait
>         for anyone
>         and play stuff the second you get it.
>
>         [...]
>          
>
>             So here I'll walk through an example... the hug:
>
>             To synchronize a hug all that is needed is for the    
>
>
>         "all that is needed" to accomplish YOUR needs and views.
>         For me, I realllllly need to know when other clients are
>         ready too.
>
>         [...snip...]
>          
>
>             be longer for some clients than others.  The exact wall
>             clock delay does not
>             matter since the end user has no idea when the event was
>             actually sent.
>                
>
>
>         Yes we totally disagree here, and you are wrong: there are
>         many other
>         shared experiences (typed text, and remaining movement of the
>         avatar
>         before and after; not to mention voice chat) that need to be
>         more or
>         less in sync with gestures; the user WILL have an idea when
>         the event
>         was sent.
>
>         The wall clock DOES matter - certainly when the delay can run
>         up to a whole minute.
>
>         You are "right" for delays less than a second, and I argue
>         that we should try hard to get the shared experience synchronized
>         within one second IF THE USER(S) SO DESIRE.
>
>         I already gave you examples where it is notable when the delay
>         is larger, but I guess every example is personal. If YOU don't
>         care that your friends see you bolt for the door and once outside
>         you jump and shout "Whooohooo!", while you really intended to
>         first jump and shout and THEN run for the door, then well--
>         that is entirely your choice. Now let me, and others, have mine.
>
>         Another example, your hug: You initiate a hug request (your client
>         already has the needed assets or starts to download them
>         immediately).
>         By the time that your partner clicks 'Ok', your viewer is ready
>         and immediately starts to play the hug. While hugging you say:
>         "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees
>         that text while they don't see you hugging yet; others do however.
>         Because others DO, we NEED support in the protocol to know when
>         other clients are ready (at least, have all the needed data
>         cached; any other delay is too short to be bothered with-- I'm
>         with you on that then).
>
>          
>
>
>     _______________________________________________
>     ogpx mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ogpx
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>