A proposed plugin architecture for diaspora:

[Michel Bauwens]

via Sam Rose:

 

http://bugs.joindiaspora.com/issues/311

Here's what I wrote:

"We're experimenting with "plugin" architecture ideas for diaspora.

We have a simple idea that is based off of the
http://flows.panarchy.com draft RFC

Our idea is to basically keep the "plugins" completely outside of the
diaspora application. We think it could be worth thinking about making
plugins/extensions that work with diaspora across a plurality of
application layer protocols. "Plugins" could be coded in any
programming language, provided that they conform to the diaspora API
in terms of how they deal with data objects, and the plugins would run
as a webservice with a variety of access/availability rules. The
advantages here are that the problem of "my diaspora pod does not
support that plugin" is effectively eliminated. As new types of
content are available for sharing, if special functionality is
required for making the new type of content viewable or usable in
diaspora, it can live as one or more services available on servers to
accomplish the needed processing. Diaspora instances could be set to
use specific "plugin" services/sources, or could look for next nearest
service available from a distributed registry for instance.

I thought that now is a crucial time to think about a scalable way to
allow people to develop extensions for diaspora in parallel. Keeping
them outside of diaspora codebase keeps the code clean and lean and
easier to refine without the burden of keeping extensions and plugins
up to date because they are tightly integrated into the application.
The extensions can instead be joined via external-facing API that
supports multiple protocols. What do you all think?"

--
--
Sam Rose
Future Forward Institute and Forward Foundation
Tel:[phone]
Cel: [phone]
skype: samuelrose
email: [e-mail]
http://forwardfound.org