On Sep 5, 1: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.
I think we should keep building it with Habari. That also makes it
much more accessible for the community: if you know Habari, you know
how to post a plugin. It also should ease the learning curve for
further development.
I think we need ACL before this can really be done effectively. Once
that's implemented, we would simply need a way for people to request
accounts.
In terms of documentation, I think the best method would just to have
the plugin modify the publish 'page' page to add an optional "plugin"
dropdown. It would then associate that page with a plugin, which would
allow you to link up pages to plugins. We would possibly replace this
with subpages once such functionality comes along, but I don't think
we should wait for it.
> 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.)
I certainly find the idea of using an XML file instead appealing. It's
good for both consistency, this use, and long-term readability.
What if we simply add a field on the publish page where you can point
to the URL of:
1) The SVN directory (this need not be hosted on -extras)
2) a zip, which would be unzipped and parsed to find the relevant
data.
> 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.
Agreed–it should allow a download from absolutely anywhere (using the
method I outlined).
> 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.
I think this system makes sense. We should allow you to point to the /
tags directory and have that be parsed/monitored for releases.
It would then automagically fill in the compatibility. In terms of a
zip, we should assume every time the zip is changed that it is a
release.
We should only display compatibility _if_ there is svn evidence that
such compatibility exists. (Assume incompatible with new versions,
till someone makes a tag as such.)
> 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...
I'd be happy to get involved–I've just never seen where this
development is happening.
I think we should definitely stick with Habari, especially given the
FormUI improvements.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
