#28 AndroPlugins (Extensions or applets?)

[Donald Organ]

create an interface to allow for AndroPlugins to be created such as an interface to the Flickr API, google maps API, google graphs API, Amazon API.

Plugins could be on an GLOBALS scape or application scape. Such as global plugins would be created inside of lib/plugins and application plugins would be created inside of application/plugins.

A standard interface would have to be created for initial creation of the plugins but then methods would be relative to the plugin, for instance:

$gMap = new AndroPlugin( 'googlemaps' );

Would look inside of lib/plugins for googlemaps and if it doesnt find it there would look inside application/plugins for googlemaps and if it doesnt find it there throw an error other wise it woudl create the object.

We would have to define an interface so that plugins are required to have certain functions

<?php
Interface AndroPlugin {
function requiredFunction() {

}
}
?>

[Donald Organ]

Logged In: YES
user_id=1268217
Originator: YES

As a way to give AndroPage access to AndroPlugins we would need to classify plugins in two formats:

1) UI - googlemaps, flickr
2) Data - paypal, authorize.net

In order to give the user complete access to UI type AndroPlugins inside of smarty we would need to create a smarty plugin that allows access to UI type plugins.

This idea is rapidly evolving but will be a great addition.

[Kenneth Downs]

Logged In: YES
user_id=1711200
Originator: NO

I really like this and eventually I'd like to see most of Andromeda's features broken out into plugins that go into a core bit of code.

With respect to UI vs. Database, it should be no trouble to simply have a plugin use what is available. If a plugin has db elements, they get built, if there are none, then nothing happens to the DB. If they have special UI screens great, if not, that's great too.

If we do it that way, then the real question becomes, how do we package and deploy a plugin? Perhaps a directory structure like this:

plugins/
plugins/googlemaps/
plugins/googlemaps/browser
plugins/googlemaps/server
plugins/facebook/
plugins/facebook/browser
plugins/facebook/server

The build process would scan through the "server" directories looking for .dd.yaml files, and at runtime the "server" directories would be added to the search path.

Or perhaps there are two tracks:

plugins-public/
plugins-public/googlemaps
plugins-public/facebook

plugins-server/
plugins-server/googlemaps
plugins-server/facebook

[Kenneth Downs]

Donald, are we still seriously looking at this? Or should we close it as superseded?

[Kenneth Downs]

Donald, are we going to pursue this?

[Kenneth Downs]

I'd like to weight in. I'd like to call them extensions, or maybe applets?

An extension would be a combination of any of these optional components:

1) A YAML file describing tables
2) Code snippets for special-purpose triggers
3) One or more PHP classes
4) One or more Javascript classes

I have bumped this up to priority 8, for right after Release 1