Oh, and just to clarify, I also mean that effort for *authors* should be taken into account.
On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebohle <iluet...@gmail.com> wrote: > Jehan, > > I wholeheartedly support your concerns, but I would advise trying to think > of ways of approaching this in a simpler way. If the registry can support > you in that, let me know. > > Other than that, the whole searching and browsing UI is likely far from > trivial as you suggest. > > cheers > > > > On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès > <jehan.marmott...@gmail.com>wrote: > >> Hi, >> >> On Thu, Apr 10, 2014 at 4:06 PM, scl <scl.gp...@gmail.com> wrote: >> > 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. >> >> All this topic is one I am myself very interested too, and I actually >> have been thinking about it for 6 months. >> If we had been a Gsoc mentor organization this year, I was even hoping >> we could find a student willing to kickstart such a plugin management >> infrastructure (this was in my personal list of gsoc ideas meant to be >> merged with the rest: >> http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas ). >> >> Now if someone wants to take care of this, I am all for not >> overworking myself. :-) Otherwise, I would likely tackle the issue >> properly in a several months. I am currently farming alpacas :P thus >> in the impossibility to focus on such an important problem, but in end >> of May I will be much more dedicated to GIMP again (though I have >> several GIMP-related priorities at this time, before even thinking >> about a plugin management system). >> >> Now before I become silent again, I will still raise what I believe >> are much important problems than any technical issues: security and >> responsibilities of the GIMP project. If that had been a gsoc project, >> I would have given most of the technicalities to the student and would >> have taken care of security personally. >> Basically having a website where anyone can upload anything and anyone >> else is fully responsible for checking oneself and installing manually >> is one thing. But providing a plugin management system, released >> together and integrated with GIMP, which would download and install on >> the user's behalf, and even auto-update plugins is a completely >> different matter. If not mistaken, there is no proper sandbox for GIMP >> plugins, so they are technically executables that GIMP runs and which >> can do many kinds of nasty stuff. We suddenly have a much more bigger >> responsibility: >> >> - We must not accept anything without at the very least a minimum of >> check. Ideally we would need security analysis programs to >> automatically review each and every code uploaded (calls to third >> party URIs, attempt to access networks, system calls which are likely >> not normal in a GIMP plugins, etc.), then technical-minded >> contributors to review codes of any suspicious plugin (being the case >> when the previous automatic review did pick up some strange patterns) >> for any funny story (scam, attacks, using your computer as a ghost >> machine, etc.). We could of course start with a self-managed community >> (abuse button, vote system, etc.) until some admin steps in to install >> code review scripts, and enough users step in into code review duty. >> Many Free Software started their plugin management this way. >> Though obviously even with such a community system, I would feel fine >> only with at least a minimum of check. >> >> - We should definitely not accept uploaded binaries. For me, this is >> an absolute *no*. Binaries are black boxes. What it means is not that >> C plugins should be forbidden but that the C plugin devs should upload >> their source code *only*. And we should have compilation systems >> running on our servers to compile C code for at least each of the 3 >> main platforms, both 32 and 64bits. That's already 6 compilation >> processes to take care of (and we still forget some platforms like BSD >> or Solaris!). >> That is very cumbersome. But I will absolutely never condone >> automatically uploading then installing binary executables into user's >> computers, coming from any random dude on the planet. >> >> - Users should always be able to see the code which is running on >> their computer. So even for binary plugins, we must at all time keep >> the codes, and keep them available to users. I don't speak about >> licenses. I obviously prefer Free Software licenses, and if it were >> only me to decide, I'd accept only FLOSS plugins. But if ever many >> people were ok to accept non-Free plugins in the system, I would not >> mind *as long as* we can still see the code. A cool stuff about this >> could be to even provide git repositories for plugin developers >> (Wordpress does this for instance, and that's very nice). >> >> - Obviously a basic stuff should be that we must sign every plugin, or >> they must come through secure channels (SSL/TLS signed), or even both. >> Now this said, this is Free Software, and anyone can come in and >> compile GIMP after changing URIs to their personal server and modify >> public keys to match their own. Then users would trust a scam plugin >> that one thinks signed. That's a problem which can't really be easily >> fixed. One way is legal. During LGM, the topic of branding has been >> several times raised, and that could be used to this effect. We could >> effectively forbid any third party compilation to be called "GIMP" >> according to some criteria. One of the criteria would be that they >> cannot change the plugin servers and any security key that we put in >> place for user safety. >> >> In any case, when I read: >> « >> 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. >> » >> For me, it feels like a joke. That's the easy part. That's the obvious >> side and that can be coded in just a few dozen minutes. But there is >> so much more. A system which does only this part, I would never want >> it to be a part of released GIMP. If we want to do this (and I want to >> do it!), then we must do it well. >> >> Or maybe we don't mean a system part of the official GIMP release. And >> in this case, do as you want. :P >> But for something official, you have above the minimum I would care >> about for this to happen. >> Have fun all! >> >> Jehan >> >> P.S.: also to be properly done, such a system would not be only about >> downloading and installing. It should also be about managing! That >> means that a proper manifest format must be specified to keep track of >> installed plugins. This would allow proper listing, uninstallation, >> auto-updating, etc. because currently the plugin management is manual >> and thus very messy. This is not as important as the security part of >> course. But if I were to do this, I would still want to include such >> considerations from the start because that would change a lot GIMP >> usage. >> >> > 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 >> _______________________________________________ >> 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
