[sldev] VWR-10311 Enabling lip sync by default

[Melinda Green]

Clean, separable API's are themselves a type of plug-in. One of the best 
things about them is that when you cleanly "chop away baggage" (such as 
3D rendering) from your viewer, you simultaneously allow other people to 
plug that piece into other things (such as a 3D ActiveX control) without 
the baggage of the viewer that it was previously wedded to. Both parts 
can and should then be wrapped in separate test harnesses so that their 
development can continue more efficiently on separate paths with the 
guarantees that they will stay compatible with each other and without 
interdependencies being reintroduced. The work to rip apart things like 
this is hard but the flexibility it buys is huge.

-Melinda

JB Kraft wrote:
> Quite right. To explain myself, I think the viewer is getting too 
> bloated for the "average" machine and offered plugins as a way to 
> possibly mitigate that bloat as well as allow for expansion in other 
> ways unforeseen. What I am really getting at is the very same thing 
> you are speaking to here with the headless viewer for example. One way 
> to do that would be to have a plugin for the GL renderer that does 
> nothing. One could even make an ascii renderer a la ascii quake ;) The 
> script editor is another excellent candidate for a plugin style 
> framework, imho.
>
> Ultimately the goal is, I think, to move toward decoupling the various 
> sub-systems and from the sounds of it, the Lab is trying to move 
> toward that as well. How exactly that is done is another matter and 
> given the current codebase, I appeciate somewhat the problems 
> inherent. I threw plugins in as simply one possible direction to help 
> manage the inevitable bloat that long lived code bases, driven by 
> enthusiastic coders, accumulates. I picked on voice and windlight 
> simply because for me, those are things I am personally not interested 
> in. No offense intended, nor did I mean to speak directly to the 
> technical issues involved in "plugifying" those particular things :)
>
> cheers!
> JB
>
> On Thu, Apr 30, 2009 at 7:51 PM, Jan Ciger <jan.ciger at gmail.com 
> <mailto:jan.ciger at gmail.com>> wrote:
>
>     -----BEGIN PGP SIGNED MESSAGE-----
>     Hash: SHA1
>
>     ordinal.malaprop at fastmail.fm <mailto:ordinal.malaprop at fastmail.fm>
>     wrote:
>     > On 29 Apr 2009, at 20:45, JB Kraft wrote:
>     >
>     >> Perhaps a more modular approach, plugin style, might be considered.
>     >> From my own usage and perspective, voice and windlight would be the
>     >> first two .so's to go.
>     >
>     > A plugin architecture for the client would be incredibly useful, and
>     > I've promoted the idea in my own small way (rather than "hey,
>     you want
>     > something different? Build and release your own client!") for a
>     couple
>     > of years now.
>
>     Um, folks - and how exactly do you want the renderer (Windlight)
>     to be a
>     removable plugin? Windlight (as technology) are basically just
>     programmable shaders. If you remove that (turning off shaders in
>     preferences does the same), you have more or less the old style 1.18
>     viewer, graphics-wise. What exactly would this as a plugin
>     achieve? The
>     shaders are not in the main memory - they run on the GPU, so you
>     do not
>     even save that by not loading them.
>
>     Voice mentioned by JB Kraft is not even integrated in the viewer
>     itself,
>     it is an external application that you do not need to run if you
>     do not
>     want it and the viewer will work even if it is not present. So what
>     plugin are we talking about? The few floaters for controlling it?
>
>     Plugins make things needlessly complex and are not useful as a general
>     design approach for core functionality. Furthermore, the viewer
>     doesn't
>     even use shared libraries yet (everything statically linked, with the
>     exception of few a things loaded dynamically - FMOD, gstreamer, etc).
>     *THAT* is what needs to be fixed, not jumping up and down about
>     plugins
>     as a panacea.
>
>     I am trying to build a headless client based on the C++ sources for
>     research right now, and thanks to rather poor modularization it is
>     pretty difficult to do. I need to duplicate an re-implement quite
>     a bit
>     of functionality that is in the viewer already (e.g. LLAgent,
>     LLWearable
>     classes), because unless I want to pull in dependencies on XUL, the
>     viewer UI and what not even for basic things like setting agent's
>     appearance inworld I cannot use them. That is what needs to be fixed -
>     once it is done, you can pretty much build whatever client you
>     want and
>     you do not need any "plugins".
>
>     Regards,
>
>     Jan
>
>     -----BEGIN PGP SIGNATURE-----
>     Version: GnuPG v1.4.9 (GNU/Linux)
>     Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
>     iD8DBQFJ+jmPn11XseNj94gRAixIAJ42uqqUpOrC0iVotd65dSFMuy3/YwCgiiN9
>     RvgI55LUd/uRQBY6hF7JX8c=
>     =hlIx
>     -----END PGP SIGNATURE-----
>     _______________________________________________
>     Policies and (un)subscribe information available here:
>     http://wiki.secondlife.com/wiki/SLDev
>     Please read the policies before posting to keep unmoderated
>     posting privileges
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges