PluginSystemDesignDocument - Revision history

Willkg at 15:26, 6 July 2012

2012-07-06T15:26:23Z

← Older revision		Revision as of 15:26, 6 July 2012
Line 5:		Line 5:
	Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.		Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

	Covered in {{{Trac\|401}}}		Covered in {{Trac\|401}}

	== Use cases ==		== Use cases ==

Willkg at 15:24, 6 July 2012

2012-07-06T15:24:56Z

← Older revision		Revision as of 15:24, 6 July 2012
Line 5:		Line 5:
	Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.		Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

			Covered in {{{Trac\|401}}}

	== Use cases ==		== Use cases ==

Willkg: add tests section; fixed commands formatting

2012-02-26T13:53:11Z

add tests section; fixed commands formatting

← Older revision		Revision as of 13:53, 26 February 2012
Line 42:		Line 42:
	I think the plan should be something along these lines:		I think the plan should be something along these lines:

	# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running ``./bin/gmg updatedb`` for setting up db tables.		# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running {{Cmd\|./bin/gmg updatedb}} for setting up db tables.
			# Expose our testing framework. Plugins should be testable and it'd be nice to test everything in a GMG install with a single {{Cmd\|./runtests.sh}}.
	# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.		# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.
	# Database storage. Migrations, adding new tables.		# Database storage. Migrations, adding new tables.
	# Templates. Adding new templates, template blocks, ...		# Templates. Adding new templates, template blocks, ...
	# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.		# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.
	# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like ./bin/gmg copy_static_assets or something less crappy that gets filled based on config file settings		# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like {{Cmd\|./bin/gmg copy_static_assets}} or something less crappy that gets filled based on config file settings
	# Need to be able to do three different things:		# Need to be able to do three different things:
	#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...		#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...

Willkg: the beginning of a plugins system design document

2012-02-25T18:24:18Z

the beginning of a plugins system design document

New page

== Status ==

February 25th, 2012: Initial writing. Needs work.

Discussion on this document happens on IRC in #mediagoblin, on the dev mailing list and on the discussion page.

== Use cases ==

This is a set of use cases we're thinking about. It is not exhaustive.

* site flat pages (about this site, donations page, how to contribute, how to get an account, terms of service, ...)
* add restrictions to uploaded content
** restrict by file size
** restrict by type
** restrict by dimensions (height x width)
* quotas (user can only have x images on site, user can only use total of 50mb, ...)
* comment spam detection
* authentication
* additional admin web pages
* extending existing media types (Add new formats for video encoding or flash display, etc?)
* things MediaGoblin already kind of does
** Storage system extensibility
** Media type extensibility

== What makes a good plugin system? ==

# plugin management system - The following should be optimized for ease-of-use:
#* installing plugins
#* configuring plugins
#* removing plugins
#* getting status on plugins
#* getting errors from plugins
# plugin API - In order to augment MediaGoblin's behavior, the plugin needs to be able to assert itself into MediaGoblin's various pipelines. This can be done with hook, signals, registration, ...
# documentation - how to build, test, install, uninstall, and share plugins
# a place where site admin can find and download plugins

== High-level plan ==

I think the plan should be something along these lines:

# Install and uninstall the plugin with pip. Then site admins add the plugin to the INSTALLED_APPS configuration. This way it's easy to put the plugin in and out, install, uninstall, etc. Plugins will have additional configuration/setup steps that will be plugin specific such as running ``./bin/gmg updatedb`` for setting up db tables.
# Expose routing to applications. Maybe even make routing part of the configuration and allow the site admin to specify "mount points" for the various applications. MediaGoblin could either query the application for routes or just pass anything pointed towards a specific mount point to the application and let it deal with routing. I think I prefer the former.
# Database storage. Migrations, adding new tables.
# Templates. Adding new templates, template blocks, ...
# Version checking: plugins should be able to check the gmg version and throw an exception if the plugin doesn't work with that gmg version.
# Serve static files. Additional CSS, JS, images, ... Symlinks? Static assets directory that gets copied over? Should be an extensions_static directory or etc of both url and filesystem paths, some command like ./bin/gmg copy_static_assets or something less crappy that gets filled based on config file settings
# Need to be able to do three different things:
#* notification: plugin gets notified of some happenstance (maybe like Django signals). Examples: post_save, post_update, ...
#* transform: plugin gets to modify some thing as it's getting processed. Examples: context processors, adding additional template tags, ...
#* handler: plugin handles some thing and if the plugin handles it, then processing ends. Examples: authentication, ...
# Implement a MediaGoblin plugin API. Expose things that need exposing, implement stuff in the core, ...
# We can do a PyPI-like thing for plugins. Needs to allow for comments, ratings, blah blah blah.
# Build a plugin writers documentation guide.
# GMG would/could come with a set of core plugins.

=== Install/uninstall ===

TBD.

=== Routing ===

TBD.

=== Database storage ===

TBD.

=== Templates ===

TBD.

=== Version checking ===

TBD.

=== Notification, transform and handler ===

TBD.

== Execution on the plan ==

# Flesh out the plan into a better design document and get a consensus on it.
# Flesh out the design details.
# Implement initial bits and write documentation.
# Write some plugins.
# Iterate going forward: Take stock of where we're at and what we're missing, implement a new piece, ...