Zine

Idea for a Zine Plugin Database

Idea for a Zine Plugin Database

From:
LeafStorm
Date:
2010-01-15 @ 23:06
Subject:
Idea for a Zine Plugin Database
I wrote a blog post about my idea for a big database of Zine plugins,
at http://blog.leafstorm.us/2010/1/15/zine-plugin-database, and I was
wondering what everybody thought about the idea. I could implement the
site and host it on my personal site (probably at zpdb.leafstorm.us),
but even so, input and a blessing from the core developers would
probably be nice.

-- LeafStorm
"There are 10 types of people in the world - those who understand
binary and those who don't."

Re: Idea for a Zine Plugin Database

From:
Armin Ronacher
Date:
2010-01-15 @ 23:40
Subject:
Re: Idea for a Zine Plugin Database
Hi,

Am 16.01.2010 00:06, schrieb LeafStorm:
> I wrote a blog post about my idea for a big database of Zine plugins,
> at http://blog.leafstorm.us/2010/1/15/zine-plugin-database, and I was
> wondering what everybody thought about the idea.
I like the idea, but how exactly that should look like is probably
something that will change along the way.  I could imagine that the
first draft is not what ultimately ends up being the plugin database
that would work.  If you want to work on that, consider forking the zine
website and adding that database there.

> Input and a blessing from the core developers would probably be nice.
You get my blessing, and my input when you got questions :)

Early input: Tag URIs are probably not very helpful because the plugin
import name already has to be unique.  Of course it is very limited
because it has to be a python identifier, but good enough for plugins.



Regards,
Armin

Re: Idea for a Zine Plugin Database

From:
LeafStorm
Date:
2010-01-16 @ 17:20
Subject:
Re: Idea for a Zine Plugin Database
On Fri, Jan 15, 2010 at 6:40 PM, Armin Ronacher
<armin.ronacher@active-4.com> wrote:
> I like the idea, but how exactly that should look like is probably
> something that will change along the way.  I could imagine that the
> first draft is not what ultimately ends up being the plugin database
> that would work.  If you want to work on that, consider forking the zine
> website and adding that database there.

Good idea. I went ahead and cloned the website, and wrote up a draft
spec on how the plugin archive will work in the README file. (You can
check my work at http://bitbucket.org/leafstorm/zine-website/.) The
approach I decided to go with, that would put the minimum strain on
the Web server (and minimum strain on me upgrading the code) was to
have an archive folder that had the data and was served statically.
This would be the "archive folder", and would have JSON files
throughout that would describe the plugins. Each Zine version (0.1,
0.2-dev, etc.) would have its own separate archive.

When you ran 'manage.py index' or some other other indexing command,
it would generate an 'index.json' file for each Zine version, that
contains all the data lumped into one. The actual Zine Web site would
get its data from the index files.

> Early input: Tag URIs are probably not very helpful because the plugin
> import name already has to be unique.  Of course it is very limited
> because it has to be a python identifier, but good enough for plugins.

You have a good point. The Python identifier would work, though the
identifiers would be separate for each Zine version based on the way I
have the archive laid out in my draft.

Probably, the URL patterns would look like:

/extend/plugins/ - Plugin database index.
/extend/plugins/<version>/ - All plugins for a Zine version.
/extend/plugins/<version>/plugin/<importname>/ - The latest version of a plugin.
/extend/plugins/<version>/plugin/<importname>/<pluginversion> - A
specific version of a plugin.
/extend/plugins/<version>/category/<category>/ - All plugins in a category.

-- LeafStorm
"There are 10 types of people in the world: those who understand
binary and those who don't."