I would suggest going with a basic REST api (i.e., GET/POST/PUT), which then means we "only" have to think about the data format. That's a more difficult discussion, of course. If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? On Wed, Apr 9, 2014 at 3:20 PM, Joao S. O. Bueno <gwidion@xxxxxxxxx> wrote: > Hi Sven - > > It is nice to read this - > I am very interested in having it working on "the client side" - that is, a > GIMP plug-in that > could make one-click download of plug-ins, scripts and other resources > (brushes, tool settings, gradients and so on). > > Having an API SPEC for the registry would be something great, because if > the current > implementation is found lacking in some aspects, it could later be changed > with > relative little pain, provided the API is respected. > > We could build-up something that would allow users with different roles > (that is, system known " to individuals who are > reasonably well-known and accepted within their respective communities" ) > who can sign plug-ins, resources, and we should mostly try to get the build > of plug-in binaries > for windows and mac, and possibly even some distributions, automated in > some form (Jenkins > can do the building for testing purposes, I suppose we could fetch the > binaries it generates in > some form?). > > To get working going on the registry API itself, maybe we could start work > on it in > a wiki page, and in a later state consolidate that into a more stable > document that > can be rendered into code. > > > Regards, > > js > -><- > > > > > > On 9 April 2014 09:57, Michael Schumacher <schumaml@xxxxxx> wrote: > > > On 09.04.2014 14:51, Alexandre Prokoudine wrote: > > > > > The expected effect of that will be a huge increase of deployed > > > extensions and, as a consequence, an increased interest to GIMP from > > > people who write exploits. My concern is how this interest can > > > realistically be handled, because we shall be paying for a better > > > technology with an increased reputation risk. > > > > The idea here is to cut down the number of people who may contribute > > binaries, from about everyone right now to individuals who are > > reasonably well-known and accepted within their respective communities > > (for example, the various IRC channels or forums around GIMP). > > > > > > -- > > Regards, > > Michael > > GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > -- Ingo Lütkebohle, Dr.-Ing. Machine Learning and Robotics Lab, IPVS, Universität Stuttgart http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle +49-711-685-88350 PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B _______________________________________________ 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
