To better understand what I mean about tree see the following URLs. https://ci.jenkins-ci.org/api/json?pretty=true&tree=jobs[name,url] versus https://ci.jenkins-ci.org/api/json?pretty=true SAM On Wed, Apr 9, 2014 at 2:24 PM, Sam Gleske <sam.mxracer@xxxxxxxxx> wrote: > On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher <schumaml@xxxxxx>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 > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
