Re: [Gimp-developer] Fwd: Gimp Registry Future
Can be taken - but a web(designer/developer) need good specs before starting this task. There are plenty of CMS'es on the wild - most of them with many ready-made modules Joomla / Word Press/ CMSMS - they are the easy to implement (and not hard to modify). Drupal is solid and well documented for peoples who need to develop plugins on their own - especially security things... ...but before any choice to be considered - a solid set of specifications must be set (I presume there is a kind of governance on Gimp Registry - which can finalize this thing) once the goal is point by point on paper - would be quite simple to choose from already existing platforms. 2014-04-08 19:41 GMT+03:00 scl : > > > On 8.4.2014 at 10:44 AM wrote: > Gimp Registry Future > > Dear Registry Users, > > I have maintained the registry for over 15 years now, and for the last > couple of years we have had an excellent team of co-maintainers who took > on a lot of the work. However, there are some much needed improvements > which are hard to carry out based on the current platform, and the work > due to abuse is growing. We cannot continue this on our own, unfortunately. > > In particular, we really need better search and categorization > functionality, and would also like to integrate the registry more > tightly with The GIMP, such that downloading and installing plug-ins > becomes more straightforward. This new structure should also help combat > abuse much more effectively. This is no longer just a web-development > issue, but much more a plug-in development task. > > Therefore, I would like to ask /you/ for some help with that. > > Specifically, we need a plug-in which could access a back-end database > over the Internet, carry out queries, receive data in XML or JSON > format, download plug-ins, and install them automatically. Ideally, it > should also be able to display and acquire meta-data, such as ratings, > permissions required, etc. > > Any takers? > > cheers, Ingo > > > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi, I understand and support your request for a clear specification, but would say that it is something to be discussed jointly. I wouldn't presume to "demand" anything of a client-side developer. This would be more of a talk, where we see what's possible easily, what would be more effort, etc. It would be ideal if there would be a person who has an own interest in this, and can propose solutions. I guess the overall idea is to have the functionality of the current web-based registry but without discussions/comments. We could keep data entry on the web-site for a while, and have the plug-in do query and download/install only. Regarding the server-side, my preference would be to keep Drupal right now. We can fairly easily expose the existing database through the "Services" module (see https://drupal.org/project/services). Once we have a clear interface, changing either side should be possible at a later stage. cheers On Wed, Apr 9, 2014 at 1:04 PM, SorinN wrote: > Can be taken - but a web(designer/developer) need good specs before > starting this task. > > There are plenty of CMS'es on the wild - most of them with many ready-made > modules Joomla / Word Press/ CMSMS - they are the easy to implement (and > not hard to modify). > > Drupal is solid and well documented for peoples who need to develop plugins > on their own - especially security things... > > ...but before any choice to be considered - a solid set of specifications > must be set > (I presume there is a kind of governance on Gimp Registry - which can > finalize this thing) > > once the goal is point by point on paper - would be quite simple to choose > from already existing platforms. > > > > > 2014-04-08 19:41 GMT+03:00 scl : > > > > > > > On 8.4.2014 at 10:44 AM wrote: > > Gimp Registry Future > > > > Dear Registry Users, > > > > I have maintained the registry for over 15 years now, and for the last > > couple of years we have had an excellent team of co-maintainers who took > > on a lot of the work. However, there are some much needed improvements > > which are hard to carry out based on the current platform, and the work > > due to abuse is growing. We cannot continue this on our own, > unfortunately. > > > > In particular, we really need better search and categorization > > functionality, and would also like to integrate the registry more > > tightly with The GIMP, such that downloading and installing plug-ins > > becomes more straightforward. This new structure should also help combat > > abuse much more effectively. This is no longer just a web-development > > issue, but much more a plug-in development task. > > > > Therefore, I would like to ask /you/ for some help with that. > > > > Specifically, we need a plug-in which could access a back-end database > > over the Internet, carry out queries, receive data in XML or JSON > > format, download plug-ins, and install them automatically. Ideally, it > > should also be able to display and acquire meta-data, such as ratings, > > permissions required, etc. > > > > Any takers? > > > > cheers, Ingo > > > > > > ___ > > gimp-developer-list mailing list > > List address:gimp-developer-list@gnome.org > > 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@gnome.org > 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
2014-04-09 13:04 GMT+02:00 SorinN : > Can be taken - but a web(designer/developer) need good specs before > starting this task. > > There are plenty of CMS'es on the wild - most of them with many ready-made > modules Joomla / Word Press/ CMSMS - they are the easy to implement (and > not hard to modify). > > Drupal is solid and well documented for peoples who need to develop plugins > on their own - especially security things... > I think, if Ingo is talking about plugins, he is talking about Gimp plugins and not about plugins in CMS systems. Regards Tobias ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 3:27 PM, Ingo Lütkebohle wrote: > Regarding the server-side, my preference would be to keep Drupal right now. > We can fairly easily expose the existing database through the "Services" > module (see https://drupal.org/project/services). Once we have a clear > interface, changing either side should be possible at a later stage. Personally, I'm mostly concerned about binary plugins. We support Windows, Linux, ans Mac OS X. A plugin written in C should be available for all three systems. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
.. > I think, if Ingo is talking about plugins, he is talking about Gimp > plugins and not about plugins in CMS systems. > > Regards > ..and I mean Drupal plugins for developing / improving the functionality of the actual gimp registry website - BTW - we all know that gimp plungin registry is about GIMP plugins the main topic was about web platform - what can be done to improving the security, anti spam measures and general functionality. 2014-04-09 14:35 GMT+03:00 Tobias Jakobs : > > 2014-04-09 13:04 GMT+02:00 SorinN : > > Can be taken - but a web(designer/developer) need good specs before >> starting this task. >> >> There are plenty of CMS'es on the wild - most of them with many ready-made >> modules Joomla / Word Press/ CMSMS - they are the easy to implement (and >> not hard to modify). >> >> Drupal is solid and well documented for peoples who need to develop >> plugins >> on their own - especially security things... >> > > I think, if Ingo is talking about plugins, he is talking about Gimp > plugins and not about plugins in CMS systems. > > Regards > Tobias > > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
Alexander, the Registry currently has support for uploading binary plugins, so those could be downloaded over the interface as well. How the binary plugins arrive in the registry is a different issue. I don't have much to offer on that front, because I can't compile for Windows and Mac OS X. However, I could say that if we create an API-interface, downloading and compiling a lot of plugins could probably be automated. cheers On Wed, Apr 9, 2014 at 1:51 PM, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Wed, Apr 9, 2014 at 3:27 PM, Ingo Lütkebohle wrote: > > > Regarding the server-side, my preference would be to keep Drupal right > now. > > We can fairly easily expose the existing database through the "Services" > > module (see https://drupal.org/project/services). Once we have a clear > > interface, changing either side should be possible at a later stage. > > Personally, I'm mostly concerned about binary plugins. We support > Windows, Linux, ans Mac OS X. A plugin written in C should be > available for all three systems. > > Alexandre > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 3:57 PM, Ingo Lütkebohle wrote: > Alexander, > > the Registry currently has support for uploading binary plugins, so those > could be downloaded over the interface as well. > > How the binary plugins arrive in the registry is a different issue. I don't > have much to offer on that front, because I can't compile for Windows and > Mac OS X. However, I could say that if we create an API-interface, > downloading and compiling a lot of plugins could probably be automated. It's a wee bit more complicated. Think of e.g. security concerns. Sure, you can sit down and analyze the code of every submitted plugin, but this solution is not scalable, and a scalable solution (as in "automated check for exploits") is likely to be expensive. Which brings us back to the same old question about money and human resources. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi! 2014-04-09 14:14 GMT+02:00 Alexandre Prokoudine < alexandre.prokoud...@gmail.com>: > On Wed, Apr 9, 2014 at 3:57 PM, Ingo Lütkebohle wrote: > > Alexander, > > > > the Registry currently has support for uploading binary plugins, so those > > could be downloaded over the interface as well. > > > > It's a wee bit more complicated. Think of e.g. security concerns. > Sure, you can sit down and analyze the code of every submitted plugin, > but this solution is not scalable, and a scalable solution (as in > "automated check for exploits") is likely to be expensive. > But this is not a new problem. If you at the moment download anything from the registry and install it, it could destroy your system. This should not stop us from improving it. Regards Tobias ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 09.04.2014 14:43, Tobias Jakobs wrote: >> It's a wee bit more complicated. Think of e.g. security concerns. >> Sure, you can sit down and analyze the code of every submitted plugin, >> but this solution is not scalable, and a scalable solution (as in >> "automated check for exploits") is likely to be expensive. >> > > But this is not a new problem. If you at the moment download anything from > the registry and install it, it could destroy your system. This should not > stop us from improving it. Part of the problem right now is that there is no coordinated effort to get "official" binaries for plug-ins assigned to these - so any binary done by anyone and either uploaded a a separate entity or linked in the comments/questions is happily accepted and downloaded be the users. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 4:43 PM, Tobias Jakobs wrote: >> It's a wee bit more complicated. Think of e.g. security concerns. >> Sure, you can sit down and analyze the code of every submitted plugin, >> but this solution is not scalable, and a scalable solution (as in >> "automated check for exploits") is likely to be expensive. > > But this is not a new problem. If you at the moment download anything from > the registry and install it, it could destroy your system. Exactly. You need to 1) go, 2) find, 3) download, 4) find out, how to install, 5) install. Whereas the proposed system suggests taking away steps 1), 3) and 4). 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. > This should not stop us from improving it. I wasn't even implying that. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Fwd: Fwd: Gimp Registry Future
Interesting issue. Not directly related to my inquiry, but certainly something to be considered. I guess we have two issues: 1) Malicious binary packagers who insert exploits into otherwise harmless plugins and 2) malicious plug-in authors, who code exploits right in. Moreover, I don't think we can expect code reviews to occur. As Michael already said, one goal of the new structure is that we only let "trusted" developers and/or packagers in. Of course, this only moves the problem to deciding who is trusted, and I guess we can expect that mistakes will be made. In my opinion, this is really an issue of the gimp's security architecture in general, but one whose risk could be increased because of the relative ease of installing new plug-ins. Sandboxing might be a possibility. In the old times, plug-ins used to be executed as separate processes, so app-armor and similar approaches would be applicable. On Wed, Apr 9, 2014 at 2:51 PM, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Wed, Apr 9, 2014 at 4:43 PM, Tobias Jakobs wrote: > > >> It's a wee bit more complicated. Think of e.g. security concerns. > >> Sure, you can sit down and analyze the code of every submitted plugin, > >> but this solution is not scalable, and a scalable solution (as in > >> "automated check for exploits") is likely to be expensive. > > > > But this is not a new problem. If you at the moment download anything > from > > the registry and install it, it could destroy your system. > > Exactly. You need to 1) go, 2) find, 3) download, 4) find out, how to > install, 5) install. > > Whereas the proposed system suggests taking away steps 1), 3) and 4). > > 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. > > > This should not stop us from improving it. > > I wasn't even implying that. > > Alexandre > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > 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 -- 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] license Gimp 2.8.10
Hello, I have a question. Can I use Gimp 2.8.10 to the commercial uses? I mean, graphics done in this software. Where can i find license in the internet? Thanks ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
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 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@gnome.org > 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] license Gimp 2.8.10
On Wed, Apr 9, 2014 at 3:01 PM, Lukasz wrote: > Hello, > > I have a question. Can I use Gimp 2.8.10 to the commercial uses? Yes. > I mean, graphics done in this software. And yes. > Where can i find license in the internet? http://www.gimp.org/about/COPYING Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
What are the current statistics of uploaded scripts/plugins? It might help us to formulate a plan if we knew a little better what the current state of influx is. (Are we seeing ~5 uploads a week? 10? 20?). Also, I'm of the opinion that the registry, whatever it ends up becoming, should be focused on the task of hosting the plugins/scripts. Right now there is a sort of forum module bolted on (which is clumsy and hard to use in Drupal, imo). Do we intend the site to also be a forum? Do we just want the ability to comment on specific plugins/scripts? Ideally, I think it would be nice to see a single-purpose page focused on the scripts/plugins only. (If we think we want to institute a forum for other purposes, perhaps it could be broken out into a separate discussion for consideration?). My gut feeling is that we are not getting overwhelmed with the number of submissions to the site, and it's something that might be reasonably handled by a few volunteers to vet the entries (and yes, I am volunteering to help with this if we go this route). There would be a nasty workload up front porting old entries, but after that I think things would calm down to a reasonable workload. On Wed, Apr 9, 2014 at 8:20 AM, Joao S. O. Bueno 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 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@gnome.org > > 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@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- pat david http://blog.patdavid.net ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Fwd: Fwd: Gimp Registry Future
darn gmail default ;-) -- Forwarded message -- From: Ingo Lütkebohle Date: Wed, Apr 9, 2014 at 5:16 PM Subject: Re: [Gimp-developer] Fwd: Gimp Registry Future To: Pat David Answers below. On Wed, Apr 9, 2014 at 4:42 PM, Pat David wrote: > What are the current statistics of uploaded scripts/plugins? It might help > us to formulate a plan if we knew a little better what the current state of > influx is. (Are we seeing ~5 uploads a week? 10? 20?). > It varies a bit, of course, but 10 is a good ballpark figure, when counting both plugins and scripts. However... We get about one user registered every five minutes. That is, between 200 and 300 users a day. And those are the *successful* registrations, i.e., those that pass the text analysis and the captcha. > Also, I'm of the opinion that the registry, whatever it ends up becoming, > should be focused on the task of hosting the plugins/scripts. Right now > there is a sort of forum module bolted on (which is clumsy and hard to use > in Drupal, imo). Do we intend the site to also be a forum? Do we just > want the ability to comment on specific plugins/scripts? > The forum functionality would be stripped, as I am told that there are other good venues for such things. That said, we should be aware of the fact that commenting on plugins was sort of an accident (Drupal has comments on anything by default), but proved unexpectedly popular. I guess having both the plugin download and a feedback function in the same place was fairly compelling. A replacement should take that into account, and offers an easily accessible feedback method that redirects people to the appropriate place. > My gut feeling is that we are not getting overwhelmed with the number of > submissions to the site, and it's something that might be reasonably > handled by a few volunteers to vet the entries (and yes, I am volunteering > to help with this if we go this route). > Well... Yes, I agree, but that's a bit besides the point. This is not about replacing the back-end. We can replace the back-end at our leisure, of course, if people want that, but its working right now. I am talking about replacing the *front-end*, to integrate things more tightly with the gimp, and improve the user experience. This was a request that Michael Schumacher made, for example, and that others have also made in the past. cheers -- 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 -- 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 7:18 PM, Ingo Lütkebohle wrote: > However... We get about one user registered every five minutes. That is, > between 200 and 300 users a day. And those are the *successful* > registrations, i.e., those that pass the text analysis and the captcha. Isn't https://drupal.org/project/spambot supposed to help by checking emails against StopForumSpam's database? Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 10:18 AM, Ingo Lütkebohle wrote: > > > It varies a bit, of course, but 10 is a good ballpark figure, when counting > both plugins and scripts. > In that case, if the intention is to focus on the scripts/plugins more than anything else, then I feel this might be a reasonable number for a small team to handle manually. > However... We get about one user registered every five minutes. That is, > between 200 and 300 users a day. And those are the *successful* > registrations, i.e., those that pass the text analysis and the captcha. > > This seems to be the root of the spam problem - would we need to have user accounts in the future? If we move forward for integration, I think curated content with no user accounts might be a better option? (Not sure here, just getting ideas on paper) > The forum functionality would be stripped, as I am told that there are > other good venues for such things. > > That said, we should be aware of the fact that commenting on plugins was > sort of an accident (Drupal has comments on anything by default), but > proved unexpectedly popular. I guess having both the plugin download and a > feedback function in the same place was fairly compelling. A replacement > should take that into account, and offers an easily accessible feedback > method that redirects people to the appropriate place. > Again, this appears to really be the root of the problem. We could certainly try allowing comments again on whatever new system (or mod of the old) occurs. > Well... Yes, I agree, but that's a bit besides the point. This is not about > replacing the back-end. We can replace the back-end at our leisure, of > course, if people want that, but its working right now. > > I am talking about replacing the *front-end*, to integrate things more > tightly with the gimp, and improve the user experience. This was a request > that Michael Schumacher made, for example, and that others have also made > in the past. > I agree that this would be fantastic - integration would certainly be a fantastic path moving forward! It would just make sense to clean house overall first to make sure everything was solid before attempting to hook into GIMP in this fashion (plus - Alexandre makes a good point about support across all the OS's/bit-depths. Perhaps a first attempt should be to look at scripts, as they are usually able to run across OS's without a problem (at least script-fu)? -- pat david http://blog.patdavid.net ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Fwd: Gimp Registry Future
On 09.04.2014 17:18, Ingo Lütkebohle wrote: > However... We get about one user registered every five minutes. That is, > between 200 and 300 users a day. And those are the *successful* > registrations, i.e., those that pass the text analysis and the captcha. I think we can discard 90% of those as spammers, if not more. And any contributor of plug-ins and scripts can easily be asked to go through a more elaborate process - e.g. provide some background, past works/contributions to forums, ... -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 5:26 PM, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Wed, Apr 9, 2014 at 7:18 PM, Ingo Lütkebohle > wrote: > > > However... We get about one user registered every five minutes. That is, > > between 200 and 300 users a day. And those are the *successful* > > registrations, i.e., those that pass the text analysis and the captcha. > > Isn't https://drupal.org/project/spambot supposed to help by checking > emails against StopForumSpam's database? > We currently use Mollom, which also checks the e-mail address. We never tried module before, but I would be surprised. Spammers are fast... cheers -- 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Fwd: Gimp Registry Future
> I think we can discard 90% of those as spammers, if not more. Probably 99%... And any contributor of plug-ins and scripts can easily be asked to go > through a more elaborate process - e.g. provide some background, past > works/contributions to forums, ... > Yes, that would be the idea. Contributors would have to undergo a signup process. That sign-up process would be manual (and labour-intensive, most likely, but there you). In fact, that's probably what we're gonna do right away, anyway, regardless of how the plug-in comes along. That means bye-bye comments and forums, but I'm afraid that's just unavoidable. -- 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Fwd: Gimp Registry Future
I am _not_ a developer, just a translator, please be kind ;-) My 2(4?) cents: Plugins are (almost all) not translated. This, when comes to integrate GIMP with some plugins, bring the translated GIMP into a mess of translated and untranslated menus and functions. 1) I think that a "good GIMP plugins guide & template" should be taken into account in order to obtain a professional GIMP plugin registry 2) Some "good plugins guidelines" should be written _and_ enforced as it happens with Linux modules 3) GIMP plugins, should be grouped into some git repo somewhere 4) that repo should contain only actively supported plugins now shoot me :-) -- Marco Ciampa "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci passi. Per quanto cammini, non la raggiungerò mai. A cosa serve l'utopia? A questo: serve a camminare." Eduardo Galeano ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
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 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 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@gnome.org > > 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@gnome.org > 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 7:42 PM, Ingo Lütkebohle wrote: > If anybody could put up a wiki page for that, that'd be great. Does The > GIMP have a wiki? wiki.gimp.org :-P P.S. Also, there is no such application as The GIMP anymore, for years :) Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
> P.S. Also, there is no such application as The GIMP anymore, for years :) > so i've been told many times, but finger memory dies hard ;-) -- 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
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? This would facilitate curating a list of trusted/mature plug-ins, experimental ones, and an everything list (and ones not hosted on the registry), manage dependencies/conflicts, get descriptions, get updates, compile from source, etc. I've written (and hacked on) a few plugins, but I'm not volunteering for this - just wondering if the problem (and problems it creates) has been largely solved already. Seth On Wed, Apr 9, 2014 at 10:42 AM, Ingo Lütkebohle wrote: > 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 > 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 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@gnome.org > > > 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@gnome.org > > 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@gnome.org > 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 09.04.2014 17:42, Ingo Lütkebohle wrote: > If anybody could put up a wiki page for that, that'd be great. Does The > GIMP have a wiki? Yes, as Alexandre has mentioned already. And it is also not "The GIMP", only "GIMP". For ages :) P.S. I think everyone is subscribed to the list, no need for CC:s -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
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? -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher 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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] 6 questions about open-source?
hi everyone! I am studying an open-source subject at college, and I've been asked to interview someone who collaborate to open-source... Is there anybody who might answer the following questions? * Which are your education (formal or informal)? * Do you had previous experience on other projects before Gimp? * What are the motivations that drive you to collaborate in this project? * Do you think that this collaboration can impact your regular work? Do you think that it will affect your future work? * Do you believe that, in a near future, open-source projects will be as popular as non-free software? * What do you think about the open-source community around you? Thank you very much, Lluís Parcerisa ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
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 wrote:
> On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher 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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB
El mar, 08-04-2014 a las 09:19 +0300, Ville Sokk escribió: > On Mon, Apr 7, 2014 at 4:24 PM, Elle Stone > wrote: > > I'm still testing the other gimp/app/operations layer blend modes. But > > probably *all* clamping code should be removed from *all* layer blend modes. > > > > Elle's two cents worth > > I would like to mention that the current blending modes were created > to replace the old 8-bit ones. I was told they should be as close as > possible to the old ones (so you could open images made with <=2.8 in > 2.10 and they would look the same). There have been talks about adding > blending modes with normal formulas (without clamping and other weird > stuff) but this hasn't happened yet. I think people weren't sure how > to show both sets of blending modes in the UI. As a user following the development of GIMP, I think it would be far more interesting if the blending modes and operations work correctly and consistently with the new core. I'm aware that keeping legacy compatibility is high in the priorities list, but maybe that can be added later. From what you say, it looks like "proper" has to wait. It seems more reasonable if it is the other way around. At the moment some legacy compatibility seems to be getting in the middle every time you want to try the new capabilities of the program. Clipping and some blending modes is one of those things, and some confusing bits about editing in linear and gamma precisions too. Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Some blend modes break in unbounded mode sRGB
For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem. If the artist uses any of the color-space dependent blend modes: * Editing an image in a large gamut color space such as ProPhotoRGB produces one set of colors. * Converting the image to unbounded mode sRGB before editing it necessarily produces different colors - sometimes very different colors. For concrete examples showing how Lighten only and Darken only are color-space dependent, see http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html Can this problem be fixed? Is there a workaround such that an image can be converted from its source color space to unbounded mode sRGB, and then use the color-space dependent blend modes to produce the same colors that would have been produced if the image had been edited in the source color space instead of in unbounded mode sRGB? Elle Stone ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi, it's interesting to see what interest such a post can trigger ;-) To be honest, it wasn't me who started the discussion, I just forwarded Ingo's call to the mailing list. 'GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.' is a part of our product-vision and as far as I remember there have already been many ideas on this topic, dating back to 2003. For both the registry and GIMP the situation changes: Registry: from some or many users who know and use the registry to potentially every user who can access it conveniently from GIMP. These are millions. GIMP: From a standalone application that uses mostly local data to an application with tighter access to an online service. I think before we start losing ourselves prematurely in implementation details like programming language and data formats we should clarify the overall picture first: - What are the concrete requirements: functional and nonfunctional requirements, - user interaction, - overall technical architecture and integration into GIMP, - reuse of existing solutions like package managers, - who will also care in future for the registry and the plug-in manager? - Integration into the Jenkins builds and manpower to handle this. Examples for functional requirements: * installing only plug-ins or also other assets, * curation/quality assurance of provided assets, * metadata of the assets, * search and filter functionality. Examples for nonfunctional requirements: * performance: be fluent, also with a slow internet connection, * security, protection against abuse, * scalability (how many users will access the registry at one time or at maximum), * target platform, * maintainability (even with our given low resources). Perhaps it would - depending on our resources - first be better to cut down the registry to the necessary part we can handle, e.g. to remove the functionality that causes spam and start with a little thing in GIMP, like a clickable link to open the registry in a browser and easy to find assets folders in the Preferences. Kind regards, Sven ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
