[sldev] Suggestion for viewer plug-ins

Lawson English lenglish5 at cox.net
Sat Jun 28 12:38:25 PDT 2008


Edward Artaud wrote:
> Unfortunately, I do have to agree with that point.  The viewer 
> urgently needs to be refactored to be modular, my hope was that a 
> strong push towards a plug-in architecture would go hand in hand with 
> that.  However, even though it's not ideal, it still should be 
> possible to bolt a plug-in API on to top of the current viewer 
> architecture.  I think this would drive the rest of the codebase 
> toward modularity as, over time, more new functionality was added via 
> the plug-in API rather than in the core code.
>
I think a big issue is: what is "core code?"

As part of the design of the pyogp, we're having to figure out just what 
code goes into what module. The nice thing about using  ZCA (Zope 
Cmponent Architecture) is that it gives us a plug-in architecture "for 
free."

In fact, I'd say that ALL of pyogp will likely be nothing but plug-ins 
before we are done and that each major module will have its own 
sub-modules, which will also be plug-ins.

This isn't quite what you had in mind, but the structure we come up with 
may help guide designing the plug-in architecture for the C++ GPL client 
(pyogp is Apache v2 licensed).





> On Sat, Jun 28, 2008 at 11:05 AM, Lawson English <lenglish5 at cox.net 
> <mailto:lenglish5 at cox.net>> wrote:
>
>     I think once thing I left out of my comments is that until the GUI
>     is refactored, a plug-in architecture won't make much sense for
>     many kinds of plug-ins because the human interface to such things
>     will be almost impossible. The way things are going, this won't
>     get done until AFTER the OGP is much further along.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges



More information about the SLDev mailing list