Habari is easily flexible enough to do this, but my gut feeling is still that this probably isn't the right way to go. Apart from a little bit of infancy still to be grown out of (ACL for example, which I know is taking leaps and bounds) this is the only area that I feel WP still out does Habari. wp.o/extend is something I really like, and it was a long time coming. If we can get Habari's version of that right it will be a huge boost for the community.
Maybe I'm just not seeing the potential, but the system you've described doesn't sound awesome to me. It sounds unnecessarily complicated. I like the idea of an SVN silo, though I'm not sure how it would be implemented. Having said that, using Habari as the system for this might open up one other possibility which I think would be awesome. How about having some kind of aggregation system so that plugin authors could post plugins on their own blogs and have them somehow automatically show up and be downloadable on hp.o. Maybe that's already been considered. As a potential plugin author I'd love that scenario. S. On Sep 5, 6:21 am, "Matt Read" <[EMAIL PROTECTED]> wrote: > 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, > seehttp://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 Readhttp://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 -~----------~----~----~----~------~----~------~--~---
