GHNS feeds for plasmaoid addons

[Aaron J. Seigo]

hi everyone...

so, what did i do on christmas day, you ask? ok, you didn't.. but i'm going to 
tell you anyways.. :P

besides sniping a couple of bugs, including a showstopper in the system tray, 
i decided to stop waiting for manna from heaven and to look into what it will 
take to get a GHNS feed for our plasmoid addons. this becomes more of an issue 
for me personally as the share plasmoid is movings most of the backends out of 
the default install, which is The Right Thing To Do. other widgets that rely 
on network services which are notorious for random changes over time, such as 
the weather engine, really ought to be doing this as web developers 
demonstrate time and again that they haven't got a clue when it comes to 
service stability.

to my great surprise, it looks very easy to do. using the OCS documentation[1] 
i have come up with a design. i budget 2 days of work to have it up and 
running. yes, that's how trivial it is, and i'm now ashamed for not having 
just pulled up my boots and done this sooner.

here's how i see it working:

we'll have a repository that we maintain. the layout of the repo will be as 
follows: each "feed" (e.g. for share widget backends) will have its own top-
level directory. in that directory, there will be a file named "config" which 
will be a simple ini style file with entries such as:

	name=org.kde.plasma.share
	compression=zip
        compresedFileSuffix=.plasmaaddon
	metadataInPayload=true

other compression values can be tgz, tbz, none. in the case of "none", the 
file in the contents directory will be assumed to be the payload. otherwise, 
the payload file will be compressed on the server side with the requested 
compression system.

inside that directory will be one directory for each item, e.g.:

	share/imagebin.ca
	share/imageshack.us

the names of the directories be used for the name of the payload file created 
(if needed).  in each of these directories will be a payload/ directory, an 
optional preview image and possibly the metadata file.

depending on the values in the config file, an INI file will be looked for 
either in the payload/ directory or in the top-level directory (e.g. 
share/imagebin.ca/metadata.desktop) that contains .desktop + X-KDE-PluginInfo 
style information so we can get names, descriptions, etc. for our plasma 
stuff, that metadata.desktop file is already in the package, so will be in the 
payload/ directory, saving us from having to sync this ifo too much.

on the server, a git pull will be done on a cron job and a script will index 
the contents. thanks to git log + some trivial text processing, it will be 
possible to only index that which has changed since the last update keeping 
this relatively scalable.

a set of static files will be written out by the indexing process:

* provider files, one per top level directory (aka "feed")
* categories listing, one per feed

static files for licenses will be there as well, though just not touched by 
the indexing (unecessary). distributions and homepagetypes will all be left 
empty with static files as well. dependencies is something i'll leave for 
later.

packages will get made if needed and the information will be cached in a 
simple database table. php scripts will be written for list, get and download 
functions and will use the database to return results. this is the bulk of the 
work, but even those are pretty straight forward as we don't need to deal with 
authentication (it's all public data).

adding, editting, favourting, etc. will not be supported.

the end result is that we will have a git repo where we can shove things into 
and which will then magically appear in our GHNS feeds. creating a new feed 
will be a matter of creating a new directory. 

update frequency on the server will depend on how much CPU and disk the 
indexing takes. i'm hoping to make it hourly.

this is not intended to be a way for random users to upload their own stuff; 
kde-look.org can be used for that.

i will initially host it on plasma.kde.org and if it proves itself to be Good 
and other projects express an interest in it then we can think about moving it 
somewhere more KDE-generic.

i have prototypes the git handling and sketched out the db on paper. if you 
have any ideas / input / corrections to the above, please do so over the next 
day or two as i don't plan on spending a bunch of time on it. i won't be 
starting today or tomorrow (already booked for other things), but should be on 
it by tuesday. i am not interested in something big or general purpose, just 
to implement something specifically for our need to push well-known addons 
very easily from upstream.

[1] which, sad to say, i'm unimpressed with. the API is not very well designed 
and the xml return values are undocumented except for example snippets :/

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101226/b8645195/attachment.sig