[sldev] Suggestion for viewer plug-ins

Lawson English lenglish5 at cox.net
Sat Jun 28 11:05:30 PDT 2008


Edward Artaud wrote:
> I certainly will get involved with that effort, but if the evolution 
> of the viewer is at all similar to that of the browser, I strongly 
> suspect that trying to design the OGP in advance of the plug-in model 
> is going to result in a much over-engineered OGP.  I think one similar 
> analogy would be the way the W3 API bindings for the XML DOM evolved 
> out of the DOM API's that were originally exposed for the use of 
> plug-ins and scripting - plug-ins were introducted by Netscape in 
> 2.0b1 in 1995 but the DOM API didn't get to the W3 until almost two 
> yearslater.  One could have made the argument that browsers should not 
> have implemented a plug-in model that allowed the Acrobat plugin to be 
> developed until the W3 developed CSS or allowed Flash to be developed 
> until the W3 finished the SVG spec (i.e. completely different 
> approaches to solve virtually the same problems that wouldn't have 
> occured through a centrally planned roadmap, but which would have 
> arguably hampered the growth of the web if a governing body like the 
> W3 took the approach of dictating rather than recommending browser 
> architecture).  Further, many viewer plug-ins will make only minimal 
> use of the OGP, much the same way that many browser plug-ins only 
> really use the browser's display API's.  I really do stand by the idea 
> that if we're trying to embrace the idea of emulating the openness of 
> the web, we can't pick and choose which parts of that open ecosystem 
> we like, but must try to open as many extension points as possible and 
> let the market drive direction through people trying a lot of 
> experiments, with standards efforts following and formalizing rather 
> than trying to predict the future.
>

I think once thing I left out of my comments is that until the GUI is 
refactored, a plug-in architecture won't make much sense for many kinds 
of plug-ins because the human interface to such things will be almost 
impossible. The way things are going, this won't get done until AFTER 
the OGP is much further along.

>
> On Fri, Jun 27, 2008 at 10:40 PM, Lawson English <lenglish5 at cox.net 
> <mailto:lenglish5 at cox.net>> wrote:
>
>     Edward Artaud wrote:
>
>         I've documented my thinking about the requirements for a
>         viewer plug-in model in a Jira entry:
>
>         http://jira.secondlife.com/browse/VWR-7970
>
>         There are some discussions of plug-ins in the wiki
>         (http://wiki.secondlife.com/wiki/Plugin_architecture),
>         however, I don't think they fully convey the importance of
>         this capability for the evolution of the platform or mention
>         the requirement for plug-ins to actually participate in the
>         rendering pipeline.  I'm increasingly becoming convinced that
>         in order for SL to be a viable platform for professional
>         content, that such a plug-in model will be required if for no
>         other reason than for third-parties to be implement the
>         content protection and access to secure assets they need
>         outside of the open-source codebase.
>
>
>     My own belief is that a plug-in architecture won't make sense
>     until the OGP is much, MUCH further along. The current protocols
>     and set of libraries is just too convoluted and organic to allow a
>     viable plugin system to be designed. By the time ti could go
>     "live" in any meaningful way, the underlying architecture will
>     have changed too drastically for any plug-in that was designed for
>     the current system to still be usable.
>
>     If you want to experiment with plugin designs for SL, join the
>     pyogp crew and steer SL's viewer-server protocols  in a direction
>     that makes a robust plug-in architecture viable in the long-run.
>
>
>     http://wiki.secondlife.com/wiki/Pyogp
>
>     Lawson
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges



More information about the SLDev mailing list