Re: [Gimp-developer] Fwd: Gimp Registry Future

[Sam Gleske <sam mxracer gmail com>]

On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher <schumaml gmx de> wrote:

> On 09.04.2014 18:03, Seth Burgess wrote:
> > Are we trying to reinvent a package manager here?  A lot of the issues I
> > could see coming up have already been addressed by apt/yum/etc - would
> > adapting one of these be a better approach than reinventing the wheel?
>
> If there is one that can be shipped with GIMP, doesn't interfere with
> the one of the system, and works on all platforms?

For now, ignoring security concerns and focusing on the server client
architecture I think this would best be served using JSON.  The client
"plugin manager" plugin can be written in Python.  The server should talk
JSON because python has better JSON support than XML (or is at least easier
to work with in my opinion although python does have good XML support).  By
"better" I meant ease to develop with.

For the server side API there should be filters on accessing the API.

For example I interact with the Jenkins API regularly and it has JSON
filters through a [GET argument tree][1].  The API should be able to filter
based on platform and language as well as other information.  The
serverside API should also allow GET arguments for filtering what results
are returned.

Examples of possible filters (of which I can think of off the top of my
head):

* id: a unique ID to identify a plugin (an incrementing int should suffice)
* platform architecture: 32-bit/64-bit/any
* platform: Windows/Mac/Linux/any
* Language (or type of plugin): scheme/python/binary
* tree: similar to tree in Jenkins where elements can be limited on exactly
what is returned.  A good example would be using the tree to filter just
the name, version, and description of the plugin only.

The API should use pagination and likely have GET options for per_page and
page (e.g. ?per_page=20&page=3).  Maybe there should be a limit for
per_page which limits how much is allowed to be returned at once as a
maximum.  This way the size of the request can be limited for the server
and plugins.  The plugin manager can iterate across pages.  Alternatively
for the initial plugin listing there can be a per_page=all and the tree can
be used to filter out all information except for name, version, and
description (or just the name and version).  That could look something like
this... ?per_page=all&tree=name,version,desc.

The Jenkins tree filter also handles structures in a sane manner.  Take for
example the following JSON.
{
  "id": 1,
  "name": "my-plugin",
  "version": "0.0.1",
  "info": [
    {
      "author": "Sam Gleske",
      "displayName": "my plugin",
      "desc": "This is my plugin"
    }
  ],
  "source_url": "http://url-to-source/my-plugin_0.0.1.tar.gz";
}

And let's say we send a GET request to the plugin server with the following
arguments: ?per_page=all&tree=name,version,info[displayName,desc] .
per_page=all would theoretically return all plugins in the API with
information filtered by tree.  As a result of the GET request the server
would respond with...

{
  "name": "my-plugin",
  "version": "0.0.1",
  "info": [
    {
      "displayName": "my plugin",
      "desc": "This is my plugin"
    }
  ]
}

This is essentially how the tree filter in Jenkins works and I think it
would benefit the plugin registry on limiting the size of the payload
returned based on the request.  By doing that the plugin manager can
initially request basic information, and if the user wants to see
additional info about the plugin then the plugin manager can make an
additional request.  The plugin can then create the following request.
?id=1 and the server responds with the full payload of everything
associated with the plugin ID (or the payload can be filtered with tree).

SAM

[1]:
http://developer-blog.cloudbees.com/2013/05/taming-jenkins-json-api-with-depth-and.html