[sldev] Suggestion for viewer plug-ins

[Edward Artaud]

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.


On Fri, Jun 27, 2008 at 10:40 PM, Lawson English <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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080627/5521cab1/attachment.htm