[opensource-dev] Plugins/Modular architecture

[Talia Tokugawa]

Well this is taking things quite a bit further than I envisioned for this.
What Glen is suggesting here seems more like having stuff like java and
flash installed for a browser.
Where I was going with this was mainly just with the UI.

The UI system code be further cut into pieces which was where I was going
with this.
So take the LSL editor for example. I'd say that the vast majority of people
within Second Life don't ever code. So what is the point of having that in
the "basic" client? strip that out totally and then offer a plugin/extention
that would reintroduce an lsl editor to people if they so choose. You could
additionally have say the emerald lsl-editor as an additional plugin
featuring extra features (like the prebuilt extra scripts and cases).
There are so many things in the basic client that I really doubt people
actually bother to use. Windlight editors, (as I said before) a large amount
of the standard edit window, estate management tools, etc etc
This is just stripping out what we have in the current viewers. Really
getting back to basics as 2.0 "tried" to do. I think once we have a firm
foundation that is simple enough for a new user not to get scared then that
is what is going to keep user retention up. Once there is that with the
viewer and a plugin system that can cater to more experienced users the sky
really is the limit.
Plugin development is a much easier task for developers than viewer
development. Currently there is a small number of developers that work
towards new viewer. Either highly dedicated individuals (kirtsen) or groups
(emerald or imprudence). As Morgaine said viewers are "monolithic". Plugins
are so much less daunting for most developers to build.

Old style viewers had this all out in the open, which was great for power
users of Secondlife and probably the main reason behind emeralds prevalence
in the viewer market. Everything a long term user wanted was right there.
2.0 tried to keep this functionality but at the same time bury enough of the
more complicated stuff in menus so that new users were not scared, that
doesn't really solve either issue. New users as they dig further keep
finding new stuff and are probably left with a sense of "How much further do
I keep digging before I get this program?". Older users are left with the
annoyance of having to dig when they are used to everything being right
there. (I know I am)

So in this nice pluggable future, as a quick case study, lets take a look at
communications. Currently we have Local, IM and Group.

   - Emerald explored the possibility of using IRC too (personally I never
   used it). There is another plugin.
   - In the snowstorm backlog there is mention of a skype intergration
   (personally I switch to skype for long conversations as it's more reliable
   than vivox). Another plugin!
   - Moving on from there.. XMPP? (again I use gchat to talk with people
   people can't always get inworld and lets face it im>email is not exactly the
   best option).
   - How about some microblogging? twitter panel maybe?
   - And if we are really going the social route.. what about full open
   social intergration ala facebook apps? (Talia is currently dancing at so n'
   so location [slurl]... Talia is planning to goto X event [Link])

Very quickly you start getting some very nice integration with many other
services. So many plugins spring to mind when you start look at the SL
viewer as a modular system. You could have say for example "plugin bundles"
so say you could have a scripter bundle (lsl editor, script debuging tools
eg, avatar scripts from emerald, script times in estate tools etc etc).
Could have social networking bundles? say a twitter user bundle giving you a
twitter stream in your communications area, Twit this tools on events
windows, parcel details and personal profiles, maybe even snapshots to
twitpic? How about google junkies bundle.. xmpp gchat for you comms, lots of
nice "buzz this" (shudders) features dropped into the interface, "add to my
calendar" buttons for events, snapshot to picassa.

Long story short here. I don't believe it's possible to make a viewer that
covers all users. Every user has different use criteria Trying to fit every
peg into a round hole just ends up with broken pegs.

T

On 4 September 2010 03:54, Glen Canaday <gcanaday at gmail.com> wrote:

>
> >
> > 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
>
>
> _______________________________________________
> 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/20100904/9bffc3f8/attachment-0001.htm