On Sun, Oct 4, 2009 at 12:34 PM, Stephen wrote:

-anything you would like to discuss.

for me, as both distributor(FX foundry) and a user resource distribution means mostly a simple way to package and deploy resources. For example, currently there are some scripts I wont distribute with foundry because they have dependencies in shape of say patterns and it would make installing the whole package very difficult.

multi-resource packs should be installable by just dragging the pack on gimp ui. It should also offer ways to uninstall and package them, and provide means for mass taging/untaging and distributing tags.

On 10/04/2009 11:34 AM, Stephen wrote:

I would like to work on Bug 306713 - Write a GIMP plug-in and resource distribution system
https://bugzilla.gnome.org/show_bug.cgi?id=306713

Cool!

-instead of providing downloads ourselves, we could make third parties the download providers and just provide say a sample implementation of a download service.

Since we don't even have someone maintaining the website I don't think it is realistic to aim for maintaining a resource server either.

I think it should be possible to specify resource servers much in the same way you would add repositories to Debian's APT. It needs to be easy to add resource servers, and it needs to be easy to configure what resource server to use (so that distros and people can host their own servers).

Also, don't forget to make sure there is support for resource tagging, and that we eventually want to rewrite our data infrastructure to use a plug-in system (so that it is easy to add e.g. a SVG brush loader), and that we will obsolete data formats and add new ones. This might or might not have big impact on the final solution

BR, Martin

Any technical comments on this solution?

I think I will just say scratch that idea, it would work for installing but it was not well thought out otherwise :).

**** Anyhow, I posted on the GHNS mailing list, mostly quoting Alexia Death and asking if anyone has used ghns for dependencies before. The response :)

On Mon, 2009-10-05 at 02:05 +0200, Josef Spillner wrote:

Packages which are unpacked at installation time and expand to several folders at once are easily possible and are already in use. However, dependencies between GHNS entries are not supported, each entry needs to be usable on its own or describe dependencies in its documentation.

It would be nice to know some details about the Gimp use case to see whether something can be done about it and how representative it is of general potential GHNS usage in Gimp. I would like to see GHNS support in there, even if it won't cover all use cases at the beginning.

Can anyone provide (a) use case(s)?

For me it comes down to our product vision "GIMP is user-extendable by one click install of addons" (not quite verbatim, gui.gimp.org keeps going down for me) What is the point of that if we have to remove 3-15 things for every addon (mis-clicks could be very painful). If you are allowed break dependencies through the interface then have a script/plugin throw an error message saying brush-x-y-z is missing and I can't work fix-me OR avoid my menu entry (no-doubt this is the way some people would choose to go). That for me is painful, but I am unsure how to phrase this as a use case

regards,
Stephen.

On Mon, Oct 5, 2009 at 10:41 AM, Stephen Craig Griffiths wrote:

Can anyone provide (a) use case(s)?

I've also told about my main use for such a thing. Having an in-gimp way to provide this functionality would be cherry on the cake.

I can agree that a package needs to be self contained, no deps to a gazillion things, however super-packages(packages that contain self contained packages) should be supported.

Lest see what I can provide as use cases.

1.0 Obtaining extras

1.1 Extras channel - User has set up channels for extras, Everything they provide is listed in a searchable package manager ui, by default orderd by download count. This UI needs to be a separate binary because it should be possible to invoke it both from within gimp and stand-alone, because to use some resources, gimp needs to be restarted.

1.2 Downloaded extras package - User should be able to simply downaload a package, drag it to package manager, and have it installed.

1.3 Requirements on installing 1.3.1 Installing newer versions of already packages installed must update existing package, (removing resources that are not included in the newer, replacing what existed, installing new) 1.3.2 If there is no package upgrade, but some resources of a package exist from an other, user has to choose whether to abort install, or make both colliding packages unmanaged and just overwrite the overlapping files.
1.3.3 If overlap exists with unmanaged resources, warn that they will be overwritten and become managed if user chooses to proceed. 1.3.4 It must be possible to install tags for resources along wit them

2.0 Removing extras 2.1 Removing packaged extras - user selects a packaged extra and tells te UI to uninstall. All files form that package are removed. 2.2 Removing unpackaged extras - UI provides an interface to mark and remove the extras that are NOT managed in packages.

3.0 Packaging - In the unmanaged resources UI, user is allowed to pick/mark resources and give a command to form a package. This will create a redistributable package that contains all the marked files and packaging info.

3.1Tagging at packaging - It should be possible through the packaging UI to add tags to multiple selections of resources.

4.0 Requirements on channel - To set up a channel, nothing more than a web server and set of packages should be needed(ok, perhaps a key pair too).

5.0 Security requirements - Since plug-ins are one of the resources packaged(and they are essentially executable, entirely usable as malware vectors), It must be somehow verified that the provider host is what it claims to be and even then, user needs to be asked fro confirmation if anything executable like a script or a plug-in is installed.

On Sun, Oct 4, 2009 at 1:34 PM, Stephen wrote:

I would like to work on Bug 306713 - Write a GIMP plug-in and resource distribution system
https://bugzilla.gnome.org/show_bug.cgi?id=306713

Just one thing. These days resources like *.gpl and *.ggr can be used by more apps than just GIMP.

We already have inkscapestuff.org and inkscapestuff.org around that are ghns based. So if you are going to implement client side in GIMP, please make sure users can add multiple resource providers.

Alexandre

I know that plugins and scripts are only s subset, but there is a bit of discussion (not around a distribution system per se, but) on plugin and script/management/duplication and general user confusion here: http://registry.gimp.org/node/17300

There was also a discussion on tagging scripts and plugins (at the GPR, but could be applied to the new tagging features??? can a script or plugin be tagged?):
http://registry.gimp.org/node/19193

Just some food for thought.

-Rob A>

I started off with a misunderstanding of what a content distribution system means to GIMP, after speaking to Peter Sikking (guiguru) I understand it to be:

-a process of packaging, hosting (not us, website/browser based) and then installing, where we aim to make the install, uninstall much easier than it is now.

"One click install" a user clicks on a link within a browser to "http://www.x.y/package.gimppackage" for example, it gets downloaded and the normal workflow happens as per browser/platform.  For example in firefox it says would you like to have program x automatically handle this file or would you like to just download it. where x is GIMP. I assume other browsers do similar things, yet for some time I have used Firefox almost exclusively.

"Security" I don't think I see the security argument anymore, we are not fundamentally changing the way scripts/plugins/other are installed just automating the process.  Any security here was and still would be based on trust, short of having someone with the time/skill to analyse these things.

"File format"
The way I see it now is a zip/tar.gz containing package.xml and other files, where package.xml describes the contents of a package. using a custom extension to identify it is a gimp package.

-where package.xml describes the name of each package, and files contained version and version of gimp required to use scripts/plugins etc but only what is required for install unistall.

regards, Stephen.

p.s. currently for me it is exam season, hopefully followed by summer-job season :), so as usual the winds determine the amount of time I have to spend.