On Thu Sep 30 18:17:40 PDT 2010, Aleric Inglewood wrote:<br><div style="margin-left: 40px;">Who is working on plugins?<br><br>I started with porting my SNOW-596 patch, but relalized that in the end<br>it would more efficient to first do plugins, then make libllcommon shared<br>
and THEN do SNOW-596 :/.<br><br>What is the progress with the plugins? Can I help to finish it?<br></div><br><br>Jacek and I were working on designs for this, but it was a long time ago, and it's fair to say that the work has stopped. I'll give you some background on it though, as I wrote up a summary of our efforts with lots of relevant links on the forum recently. This is a summary of that post.<br>
<br>General architecture: Viewer runs a socket-based listener (TCP or Unix domain as required), scripts are external programs which run concurrently each in their own process, they connect to the viewer's listener port, and communicate with it using JSON-encoded messaging. We also defined a simple Link Negotiation Protocol to allow different forms of communication to be negotiated between each plugin and the viewer.<br>
<br>A good deal of the outline design had been agreed tentatively, but progress faded while we were designing the engine architecture, mainly through a combination of not enough time, the difficulty of finding a suitable inner API in the viewer, and sheer complexity of the viewer code. The goal hasn't died though, and it's been reaffirmed quite regularly on the forums.<br>
<br>That said, we're in a different situation now with Snowstorm code in public Hg, and perhaps going it alone isn't the right way anymore. The TPVs could quite easily head their own way by exchanging changesets among themselves, without needing LL in the loop at all. On the other hand, it certainly would make merges easier if LL were on board, but I'm not holding my breath on that.<br>
<br>For reference, I've gathered some forum and wiki links to our design discussions for the plugins system here:<br><br><div style="margin-left: 40px;"><a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=79" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=79</a> - Proposal: Plugin System<br>
<a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=85" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=85</a> - Proposal: Plugin System (API)<br><a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=103" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=103</a> - [Plugins] Plugin-to-Plugin Messaging<br>
<a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=104" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=104</a> - [Plugins] Plugin Process Management<br><a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=106" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=106</a> - [Plugins] Internet vs Unix Sockets for Local Plugins<br>
<a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=109" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=109</a> - [Plugins] Event Callback Enhancements<br><a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=111" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=111</a> - [Plugins] Plan of Attack<br>
<a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=113" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=113</a> - [Plugins] Plugins as the Imprudence Test Harness<br><a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=114" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=114</a> - [Plugins] API Version & Feature Checks<br>
<a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=118" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=118</a> - [Plugins] Proposal for naming changes<br><br><a href="http://imprudenceviewer.org/wiki/Plugin_System/API%5DWiki" target="_blank">http://imprudenceviewer.org/wiki/Plugin_System/API]Wiki</a> - Proposal: Plugin System (API)<br>
<a href="http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png%5DWiki" target="_blank">http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png]Wiki</a> - Overview diagram<br></div><br>It's worth mentioning that there has been work done in other teams towards the same general goal. I know of at least two such projects:<br>
<br><ul><li>Dzonatas Sol created the SNOW-375 patch for Snowglobe 1.x, which provides a REST API linked to a number of REST resources in the viewer -- <a href="http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources" target="_blank">http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources</a> . This would allow client-side scripting to be done through socket-connected plugins, exactly as Jacek and I were planning, but with a different API (XML and REST), which is an acceptable tradeoff, slower than JSON but more flexible. At the start of September, Frederick Martian notified us that he had ported SNOW-375 to the current Imprudence head in the snow375 branch of his Git repo --- see <a href="http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=646&start=0&hilit=rest" target="_blank">http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=646&start=0&hilit=rest</a> .</li>
<li>Fred Rookstown is currently beating on his Luna viewer, which features a linked-in Lua environment with a large API of viewer bindings. This too is a good way to go, although it has very different tradeoffs to the socket-based approach favored by Dzon and ourselves: much is gained but much is also lost. See <a href="http://luna.nexisonline.net/">http://luna.nexisonline.net/</a> .<br>
</li></ul><br>That's roughly the state of play. The fly in the ointment is of course Linden's V2 viewer, and the tail-light chasing that they are forcing upon TPVs. It's hard to know how this is going to play out, but whatever happens, client-side scripting is definitely in our future somewhere. :-)<br>
<br><br>Morgaine.<br>