Difference between revisions of "SoC plugin repository"
(First draft: Plugin repository (GSoC project)) |
(added links to the 3 repositories for this project) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This is one of the projects to be implemented during the [[Google Summer of Code]] 2009. | |
| − | == Incentive == | + | '''Student:''' Tim Patrick, '''Mentor:''' Matt West |
| + | |||
| + | |||
| + | == Project info and advancement during Summer of Code == | ||
| + | |||
| + | * [[Structure and Information]] | ||
| + | * [[Developing Plugins]] | ||
| + | * [[Patches and Upgrades]] | ||
| + | * [http://www.geeklog.net/forum/viewtopic.php?showtopic=87486 Forum discussion] | ||
| + | * Repositories: | ||
| + | ** [http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2009-tpatrick/ Geeklog version with support for the Repository built in] | ||
| + | ** [http://project.geeklog.net/cgi-bin/hgwebdir.cgi/repository/ Plugin Repository plugin] | ||
| + | ** [http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2009-rmanager/ Repository Manager plugin] | ||
| + | |||
| + | |||
| + | == Pre-Summer of Code idea discussion & preparation == | ||
| + | |||
| + | === Incentive === | ||
Geeklog's functionality can be extended by plugins, i.e. add-ons that use the dedicated plugin API which allows them to be seamlessly integrated into Geeklog. The standard Geeklog distribution ships with some plugins pre-installed (Calendar, Spam filter, etc.). Other popular plugins include a forum and image galleries. | Geeklog's functionality can be extended by plugins, i.e. add-ons that use the dedicated plugin API which allows them to be seamlessly integrated into Geeklog. The standard Geeklog distribution ships with some plugins pre-installed (Calendar, Spam filter, etc.). Other popular plugins include a forum and image galleries. | ||
| Line 7: | Line 24: | ||
Traditionally, installation of a plugin was a somewhat awkward process: After unpacking the tarball or Zip archive, you have to rename and move three directories into specific places, then run the plugin installation script. | Traditionally, installation of a plugin was a somewhat awkward process: After unpacking the tarball or Zip archive, you have to rename and move three directories into specific places, then run the plugin installation script. | ||
| − | Thanks to the Summer of Code, this is about to change in Geeklog 1.6.0. Now you can upload plugins directly from Geeklog's plugin admin panel. Geeklog will take care of moving the directories into their proper place and also run the install automatically. | + | Thanks to the Google Summer of Code, this is about to change in Geeklog 1.6.0. Now you can upload plugins directly from Geeklog's plugin admin panel. Geeklog will take care of moving the directories into their proper place and also run the install automatically. |
| − | With this project, we want to take things one step further | + | With this project, we want to take things one step further and allow plugin installation over the internet. |
The idea is to provide a plugin repository from which the admin of a site can easily pick a plugin for installation. | The idea is to provide a plugin repository from which the admin of a site can easily pick a plugin for installation. | ||
| − | == Details == | + | === Details === |
To allow installation of a plugin from a plugin repository, both sides have to be implemented. So the goals of this project are | To allow installation of a plugin from a plugin repository, both sides have to be implemented. So the goals of this project are | ||
| Line 21: | Line 38: | ||
* Extend the plugin admin panel in Geeklog to allow download from a plugin repository | * Extend the plugin admin panel in Geeklog to allow download from a plugin repository | ||
| − | === Plugin Repository === | + | |
| + | ==== Plugin Repository ==== | ||
The plugin repository should be implemented as a Geeklog plugin itself. It will be installed on sites that want to provide plugins for download. Geeklog's homepage would be an obvious use case, but plugin authors may also want to provide their own repositories on their own sites. | The plugin repository should be implemented as a Geeklog plugin itself. It will be installed on sites that want to provide plugins for download. Geeklog's homepage would be an obvious use case, but plugin authors may also want to provide their own repositories on their own sites. | ||
| − | The general features are similar to the existing File Management plugin | + | The general features are similar to those of the existing File Management plugin, namely |
* allow users to upload plugins | * allow users to upload plugins | ||
| Line 33: | Line 51: | ||
The repository should allow more flexibility here, though, depending on the use case, e.g.: | The repository should allow more flexibility here, though, depending on the use case, e.g.: | ||
| − | # "Open" setup (e.g. geeklog.net): | + | # an "Open" setup (e.g. geeklog.net): |
#* any user can upload | #* any user can upload | ||
#* users can update their submission (requires re-approval) | #* users can update their submission (requires re-approval) | ||
| − | # "Closed" setup (e.g. plugin author's private site): | + | # a "Closed" setup (e.g. plugin author's private site): |
#* only dedicated users can upload | #* only dedicated users can upload | ||
#* no approval required | #* no approval required | ||
| Line 43: | Line 61: | ||
These options should be configurable. | These options should be configurable. | ||
| − | ==== Notes ==== | + | ===== Notes ===== |
* For large repositories, a category system would help to keep things maintainable and usable. | * For large repositories, a category system would help to keep things maintainable and usable. | ||
* Uploaded files should be checked automatically. For example, a minimal Geeklog plugin will always contain a file called <tt>functions.inc</tt> and should also include a file <tt>autoinstall.php</tt> to allow automatic installation. | * Uploaded files should be checked automatically. For example, a minimal Geeklog plugin will always contain a file called <tt>functions.inc</tt> and should also include a file <tt>autoinstall.php</tt> to allow automatic installation. | ||
| − | * Geeklog provides PHP classes for upload and download of files. | + | * The repository should allow "traditional" downloads from a browser, too, in case users need to do manual plugin installs. |
| + | * Geeklog provides PHP classes for upload and download of files. The download from within Geeklog can be done using the PEAR HTTP::Request package. | ||
| − | === Feeds === | + | ==== Feeds ==== |
Information about the plugins in a plugin repository should be provided as feeds (e.g. Atom or RSS). A Geeklog site admin should be able to subscribe to these feeds easily in order to stay informed about new plugins and updates to existing plugins - especially updates of plugins they have already installed. | Information about the plugins in a plugin repository should be provided as feeds (e.g. Atom or RSS). A Geeklog site admin should be able to subscribe to these feeds easily in order to stay informed about new plugins and updates to existing plugins - especially updates of plugins they have already installed. | ||
| Line 55: | Line 74: | ||
Geeklog provides a framework for reading and writing feeds in various formats (Atom, RSS, RDF). | Geeklog provides a framework for reading and writing feeds in various formats (Atom, RSS, RDF). | ||
| − | === Plugin admin panel === | + | ==== Plugin admin panel ==== |
Geeklog's plugin admin panel should get a new pane that handles | Geeklog's plugin admin panel should get a new pane that handles | ||
| Line 62: | Line 81: | ||
* selecting a plugin for installation | * selecting a plugin for installation | ||
| − | === Questions === | + | ==== Questions ==== |
Some questions and considerations to get the student started: | Some questions and considerations to get the student started: | ||
| Line 69: | Line 88: | ||
* A plugin that is installed from a repository could provide an update feed for itself. How should these be handled? This may require additional plugin API functions. | * A plugin that is installed from a repository could provide an update feed for itself. How should these be handled? This may require additional plugin API functions. | ||
* Security considerations: Ensure integrity of plugin archives (checksums). What can we do about malicious plugin repositories? | * Security considerations: Ensure integrity of plugin archives (checksums). What can we do about malicious plugin repositories? | ||
| + | |||
| + | ==== Considerations for the Future ==== | ||
| + | |||
| + | In the future (post-GSoC), we may want to extend the functionality to allow download and installation of other components, e.g. themes and language files. The code for this project should therefore be written in a way that it allows future extensions and avoids things like hard-coded paths or making assumptions that would only apply to Geeklog plugins. | ||
| − | == Level of Difficulty == | + | === Level of Difficulty === |
''medium'' | ''medium'' | ||
Latest revision as of 21:58, 24 January 2011
This is one of the projects to be implemented during the Google Summer of Code 2009.
Student: Tim Patrick, Mentor: Matt West
Contents
Project info and advancement during Summer of Code
Pre-Summer of Code idea discussion & preparation
Incentive
Geeklog's functionality can be extended by plugins, i.e. add-ons that use the dedicated plugin API which allows them to be seamlessly integrated into Geeklog. The standard Geeklog distribution ships with some plugins pre-installed (Calendar, Spam filter, etc.). Other popular plugins include a forum and image galleries.
Traditionally, installation of a plugin was a somewhat awkward process: After unpacking the tarball or Zip archive, you have to rename and move three directories into specific places, then run the plugin installation script.
Thanks to the Google Summer of Code, this is about to change in Geeklog 1.6.0. Now you can upload plugins directly from Geeklog's plugin admin panel. Geeklog will take care of moving the directories into their proper place and also run the install automatically.
With this project, we want to take things one step further and allow plugin installation over the internet.
The idea is to provide a plugin repository from which the admin of a site can easily pick a plugin for installation.
Details
To allow installation of a plugin from a plugin repository, both sides have to be implemented. So the goals of this project are
- Implement a "Plugin Repository" plugin
- Extend the plugin admin panel in Geeklog to allow download from a plugin repository
Plugin Repository
The plugin repository should be implemented as a Geeklog plugin itself. It will be installed on sites that want to provide plugins for download. Geeklog's homepage would be an obvious use case, but plugin authors may also want to provide their own repositories on their own sites.
The general features are similar to those of the existing File Management plugin, namely
- allow users to upload plugins
- require approval from a moderator
- allow users to download the approved plugin
The repository should allow more flexibility here, though, depending on the use case, e.g.:
- an "Open" setup (e.g. geeklog.net):
- any user can upload
- users can update their submission (requires re-approval)
- a "Closed" setup (e.g. plugin author's private site):
- only dedicated users can upload
- no approval required
- dedicated users can update their submissions without approval
These options should be configurable.
Notes
- For large repositories, a category system would help to keep things maintainable and usable.
- Uploaded files should be checked automatically. For example, a minimal Geeklog plugin will always contain a file called functions.inc and should also include a file autoinstall.php to allow automatic installation.
- The repository should allow "traditional" downloads from a browser, too, in case users need to do manual plugin installs.
- Geeklog provides PHP classes for upload and download of files. The download from within Geeklog can be done using the PEAR HTTP::Request package.
Feeds
Information about the plugins in a plugin repository should be provided as feeds (e.g. Atom or RSS). A Geeklog site admin should be able to subscribe to these feeds easily in order to stay informed about new plugins and updates to existing plugins - especially updates of plugins they have already installed.
Geeklog provides a framework for reading and writing feeds in various formats (Atom, RSS, RDF).
Plugin admin panel
Geeklog's plugin admin panel should get a new pane that handles
- feeds and update information
- selecting a plugin for installation
Questions
Some questions and considerations to get the student started:
- Use case: User finds a new site that offers a plugin repository. How can they easily subscribe to that site's feed?
- A plugin that is installed from a repository could provide an update feed for itself. How should these be handled? This may require additional plugin API functions.
- Security considerations: Ensure integrity of plugin archives (checksums). What can we do about malicious plugin repositories?
Considerations for the Future
In the future (post-GSoC), we may want to extend the functionality to allow download and installation of other components, e.g. themes and language files. The code for this project should therefore be written in a way that it allows future extensions and avoids things like hard-coded paths or making assumptions that would only apply to Geeklog plugins.
Level of Difficulty
medium
Geeklog already provides solutions for the basic tasks: Uploads, downloads, plugin installation, feeds. Putting them all together in a way that's easy and secure to use is what this project is about.
