[opensource-dev] Eclipse Guru's

[Morgaine]

Sai, that's exactly how we we were designing Imprudence's plugin system.

JSON messages sent by a plugin script were decoded on arrival in the
viewer's socket plugin interface, and dispatched to invoke corresponding
functions in the Viewer API.  Some API functions set up callbacks, typically
when registering interest in data expected to arrive in the future, ie.
subscribing to an event.

For example, a script might register interest in receiving incoming IM chat
for a particular group.  This would set up an appropriate callback, and then
whenever chat arrives for this group the callback would be invoked to send
the chat to the plugin as payload in an appropriate message.  Any number of
plugins could make such registrations to the same event --- for example one
plugin might feed an external graphic chat window, while another could feed
a text-to-speech synthesizer without requiring any visual representation.

In general, every event of potential interest in the viewer should be made
available at the Viewer API so that scripts can subscribe to it if wanted.
Fortunately this is not a huge task because most events share much in common
with each other, so it's mainly a job of enumeration and assigning
appropriate payload types.


Morgaine.





==================================

On Fri, Mar 5, 2010 at 12:35 AM, Lawson English <lenglish5 at cox.net> wrote:

> Ambroff Linden wrote:
> > On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin <djfoxyslpr at gmail.com
> > <mailto:djfoxyslpr at gmail.com>> wrote:
> >
> >     I do often hear complaints and wishes for new build tools, what
> >     about us LSL devs?  Some things I would like are:
> >
> >        1. Better IDE in SL Viewer
> >        2. API for compiling in LSL using various IDEs already available
> >        3. Going along with #1, as suggested, integrating Eclipse or
> >           equivalent in SL.
> >        4. LSL Wiki built into the editor
> >        5. Detachable script editing window (To develop on one monitor
> >           & test in the other)
> >        6. Entity relationship diagram system in SL viewer for visual
> >           coding.
> >
> > I'm not sure that spending whole lot of time adding fancy features to
> > the built in LSL editor is  that productive (we aren't trying to build
> > an IDE, and there are a ton of really good extensible IDEs out there
> > already), but I really like your idea of putting together an API.
> > Someone could hack a service into the viewer that lets another process
> > (like Eclipse or Monodevelop) perform limited operations on the
> > inventory of the currently selected object.
> >
> > We already have D-Bus
> > <http://www.freedesktop.org/wiki/Software/dbus> integration in the
> > GNU/Linux Viewer for SLurl support, so it shouldn't be too hard to
> > expose something like an ObjectEditorProxy. It could allow an
> > extension for your favorite IDE to enumerate the scripts that are
> > editable in the currently selected object's inventory, fetch their
> > contents, compile(), and add new scripts to the object's inventory.
> > The IDE could also subscribe to events emitted by the viewer, such as
> > ScriptAdded, ScriptDeleted, etc.
> >
> > What might improve the situation quite a bit is if the server
> > supported a capability that allowed the viewer to fetch all symbols
> > exported by the simulator (all LSL functions and constants). That
> > metadata could then be exposed to the IDE through the
> > ObjectEditorProxy for intellisense support.
> >
> > In the long run I don't know if this is a good solution, but it would
> > certainly be an interesting experiment!
> >
> > -Ambroff
>
> I like the idea of a subscription to events.
>
> What we need is a way to register a handler/subscriber for ANY(more or
> less) arbitrary event, the data of which can be shared via the same
> mechanisms as the  media plugin: socket and/or  shared memory.
>
> For security's sake, we then need a way for the user to checkbox which
> events are allowed to be handled by which plugin. The default setting
> for all events for all plugins wold be NOT ALLOWED.
>
> If we standardize the interface and plugin protocols the right way,
> non-Linden viewers can also use these plugins and the viewer
> architecture can be changed without breaking an existing plugin
> (assuming that a specific plugin makes sense at all with some future
> architecture, of course).
>
> This same system could be used by an internal scripting system ala what
> Q has talked about with mono/C# (just bypass the socket/sharedmemory i/o
> for a handler implemented in the internal scripting language) and by
> external scripting systems and plugins.
>
>
> Lawson
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100305/15be5d76/attachment.htm