[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