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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
