I've been working on the "plugin server" plugin lately, and plan to do some major work this weekend, and I have a few questions for the community. First I'll try and explain how it all works. (it's late)
We decided that to "host" plugin/themes we would actually use habari and create regular posts with a content-type of "plugin" or "theme". The "plugin server" plugin (or plugin_directory plugin) is attempting to add these extras content types and provide a customized post screen with all the necessary fields. The idea being that when you create a plugin you would then create a post for that plugin with title, content, tags, etc, then it would show up on hp.o for people to see and download and comment (http://habariproject.org/en/explore/plugins). The other purpose is to generate the "update beacon" data to display update messages on the dashboard (http://habariproject.org/en/beacon). Now, the idea I had for the plugin server, was that you create a post for the plugin with a guid, title, content, tags, author, author url, etc.. That will provide all the needed data to display the plugin on hp.o. However, each plugin will likely have multiple versions, so on top of that data you can "attach" multiple versions to a post. These version will contain version specific data, like update status, version number, habari version supported, the actual url to the download, and a description of what this update is for (eg. fixing bug x). from that data we can generate the beacon. (http://habariproject.org/en/beacon) As you see there, each beacon has an id (the guid) and a name. Within the beacon is each update for that beacon (ie. each release for the plugin). Habari then uses this data to determine if there are any updates available for the active plugins/themes and displays the update message on the dashboard. That's what the guid is for, to identify that an update to something active is available. To get and idea of all the info available on each post, see http://habariproject.org/en/packages . You see that "<versions>" can contain multiple versions per "package". Now for questions. Do we still want to use habari to host this? It would mean we need some way to allow "quasi-public" access to hp.o so people can add and update their plugin data. Would some form of a wiki be better for this? It would allow subpages, etc. for documentaion and such. But would make it harder to get the needed fields for the beacon data. Right now there is no "link" between the "plugin server" and the svn repo. And in order for scripts to parse the files for data, it's almost impossible. Can we please have plugins use an xml file for their info like themes do? and require that the guid be part of that info since it is basically what uniquely identifies the plugin in the beacon?. This would at least also allow us to parse some data to make this process of posting updates a little more "automagic". (aside: One idea I had was an svn silo that you could set the dir of the plugin, then browse the tags for each update, and have automatically enter version info and zip it up.) Do we want to host only those in svn? This question was asked before and seemed to end with a "no, allow all things", so the plugin server currently does allow a download from anywhere. Not really a question, but, the version that is in trunk is _not_ a released version, only those in tags are "released" versions. So in order for this to work, we will have to start tagging stable version for each habari version. I beleive the current way is like 0.6-1.0. 0.6 being habari version, 1.0 being plugin version. Right now, in the plugin server, I've made it so that you can declare which version of habari your plugin is compatible with; like 0.6.x, meaning any of the 0.6 releases. How do we want to handle compatibility? The current "tagging" method I mentioned above seems to fit that there will be a release/tag for each habari version. So you might make the 1.0 series of your plugin compatible with Habari 0.6 series, and 1.1 with 0.7 and so on, with point releases in between. There also seems to be some confusion about HPM (Habari Package Manager) Plugin. It has nothing to do with the beacons mentioned above or in fact with anything mentioned above. It simply takes the "packages xml dump" (http://habariproject.org/en/packages), parses it, stores it in the DB, then provides an interface for searching/finding and "one-click" installs/updates/uninstalls. Anyway that's that. If you wish to get involved, forget about hpm for now, we need to sort the how to present the admin post screen (also what feilds are needed etc.), and we need theme templates for the output on hp.o. BUT FIRST we need to decide if habari is the way to handle this... -- Matt Read http://mattread.com --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
