[opensource-dev] Plugins/Modular architecture

[Glen Canaday]

> 
> this is why now all code is public and following few step you can
> contribute all code you want... a optional switchable theme/UI/XUI can
> be merged giving to all residents the freedom to choose the aspect on
> monitor (viewer 1.x style too).
> 
> Is hard take LL base code, patch it, merge a LL-next-version to fit
> newfeatures and patch again everything, i think this way to work is
> great why all can fit a features (a single click in setup panel
> enable/disable it maybe...) without care to merge everytime a new
> features will be implemented by LL

Like I said... lots of ideas, but not enough geek nor enough singlehood
to commit as much time to this kind of thing as it would need. It's like
looking through the window at some Shiny Animal you might be able to buy
and dearly want, but you could never afford to feed and you know it. It
makes me sad, heh.

The base idea for the GROND project was only a plugin manager,
memory/data manager, and these basic plugins:

1. A UI plugin. Allows for hot-loading a UI and handles all human I/O
that isn't related to rendering or audio.

2. A viewer plugin. Allows for hot-loading renderers since all scene
information is maintained by the data manager and not the renderer
library.

3. A protocol plugin. Would allow for protocol upgrades to occur on a
per-grid basis.Each grid could provide a plugin or just a protocol spec
to handle their own grid's communications needs, so that things like SL
2's incompatibility with OpenSim doesn't have to happen again. That was
a HUGE pain trying to get used to 2.0 on my own grid... it just didn't
work.

Some extras I came up with were:

1. An audio plugin. This plugin could handle all audio input and output
to and from the viewer. This would permit the use of voice (VOIP)
technology as well as play inworld sounds and streaming. Doesn't have to
only be audio, could be a "direct gstreamer" plugin. If it ate too much
bandwidth, it could be unloaded by the user or just self-throttled.

2. A client-side physics plugin. This plugin would handle all soft-body
physics to be displayed by the viewer. Note that all rigid-body physics
must be simulated on the server, with the collisions only reported to
the client. If it ate too much processor, it could be disabled.

3. A local filesystem plugin. This one's cool. Upload / download from
within an inworld object or from your own inventory - which could
display your own local filesystem as well as your inworld inventory.

This kind of thing could easily evolve into the first viable 3D desktop
that could also integrate emerging web technologies and do it completely
transparently.

But like has been said, it's HUGE. There's no WAY I could devote enough
time to it. It's the next Mosaic, and LL's already written the first
versions of all of the most important parts.

--GC