[P2P-F] Our proposed plugin architecture for diaspora: Keep it distributed and outside of the application

[Aaron Huslage]

This is a great idea...extend from without.

I've got a newbie question though. How does diaspora maintain network
integrity? What's the federation model? What maintains security and
integrity of referential or replicated data?

Specific links to documentation are fine if you don't have time to compose a
full answer.

--
Aaron Huslage
+1.919.600.1712
huslage at gmail.com
Via mobile device
On Mar 9, 2011 9:40 PM, "Samuel Rose" <samuel.rose at gmail.com> wrote:
> 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:+1(517) 639-1552
> Cel: +1-(517)-974-6451
> skype: samuelrose
> email: samuel.rose at gmail.com
> http://forwardfound.org
> http://futureforwardinstitute.org
> http://hollymeadcapital.com
> http://p2pfoundation.net
> http://socialmediaclassroom.com
>
> "The universe is not required to be in perfect harmony with human
> ambition." - Carl Sagan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ourproject.org/pipermail/p2p-foundation/attachments/20110309/e6e6e06d/attachment.htm