Content distribution system

[Stephen Griffiths-2]

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

Martin suggested on bugzilla:
> If we do this, we should seriously consider
> http://ghns.freedesktop.org/.


****
I have had a look at the specification and written a little bit of code
to test the idea using libxml2 and libcurl.  (to understand ghns better
and because I have never worked with XML or URL based downloads)

In general it seems quite feasible and hopefully challenging for me, so
questions for discussion.

-did anyone else have plans to do this any time soon?

-Are we considering this to be only for individual users or someone
download for groups of people, in cases such as
--using thin clients?
--creating networked images?

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

-anything you would like to discuss.

Regards,
Stephen.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexia Death-2]

On Sun, Oct 4, 2009 at 12:34 PM, Stephen <scgmk5@...> 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.


--
--Alexia
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

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

--

Latest blog post Sunday, October 4, 2009:
"Single-window mode progress report"

My GIMP Blog:
http://www.chromecode.com/


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Stephen Griffiths-2]

On Sun, 2009-10-04 at 18:54 +0300, Alexia Death wrote:

> On Sun, Oct 4, 2009 at 12:34 PM, Stephen <scgmk5@...> 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.

Thanks for this, this wasn't on my radar before.

I did some thinking about this, and it ties in with what Martin said
before, download types (including versions) are identified by type using
a string, such as:

<stuff category="app/media"> (the given example)

gimp/tags/3.0.0
gimp/pattern/3.4.8
gimp/plugin/tinyscheme/3.2.3
gimp/package/

if we use the same system, but prefix each string using a checksum of
the enitre package such as:

da0b21c73078882a59430ce68e8860b9/gimp/tags/3.0.0
da0b21c73078882a59430ce68e8860b9/gimp/pattern/3.4.8
da0b21c73078882a59430ce68e8860b9/gimp/plugin/tinyscheme/3.2.3
da0b21c73078882a59430ce68e8860b9/gimp/package/

gimp/package/3.4.8/package.xml, could just be a ghnsdownload identifying
everything that is to be installed an un-installed.
And the checksum prefix identifies that it was installed as a part of a
given package

and given a network based install, you just send the package.xml, where
the package could be constructed on the fly.


Any technical comments on this solution?

How would the installed version look?
.gimp-x-y/patterns/da0b21c73078882a59430ce68e8860b9/....?

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Stephen Griffiths-2]

> 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.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexia Death-2]

On Mon, Oct 5, 2009 at 10:41 AM, Stephen Craig Griffiths
<scgmk5@...> 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.

--
--Alexia
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[RobA]

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>
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Stephen Griffiths-2]

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.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer