[impdev] Plugins

[Morgaine]

[REPOST with indentation that didn't get thro' Mailman fixed, and two URLs
corrected]


On Thu Sep 30 18:17:40 PDT 2010, Aleric Inglewood wrote:
>
> Who is working on plugins?
>
> I started with porting my SNOW-596 patch, but relalized that in the end
> it would more efficient to first do plugins, then make libllcommon shared
> and THEN do SNOW-596 :/.
>
> What is the progress with the plugins? Can I help to finish it?


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.

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.

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.

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.

For reference, I've gathered some forum and wiki links to our design
discussions for the plugins system here:

http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=79    - Proposal:
Plugin System
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=85    - Proposal:
Plugin System (API)
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=103  - [Plugins]
Plugin-to-Plugin Messaging
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=104  - [Plugins]
Plugin Process Management
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=106  - [Plugins]
Internet vs Unix Sockets for Local Plugins
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=109  - [Plugins]
Event Callback Enhancements
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=111  - [Plugins] Plan
of Attack
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=113  - [Plugins]
Plugins as the Imprudence Test Harness
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=114  - [Plugins] API
Version & Feature Checks
http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=118  - [Plugins]
Proposal for naming changes

http://imprudenceviewer.org/wiki/Plugin_System/API<http://imprudenceviewer.org/wiki/Plugin_System/API%5DWiki>
- Proposal: Plugin System (API)
http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png<http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png%5DWiki>
- Overview diagram

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:


   - 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 --
   http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources .
   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
   http://imprudenceviewer.org/forums/viewtopic.php?f=7&t=646&start=0&hilit=rest.
   - 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 http://luna.nexisonline.net/ .


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. :-)


Morgaine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.imprudenceviewer.org/pipermail/impdev-imprudenceviewer.org/attachments/20101016/031da5f6/attachment-0002.htm>