[Kde-silk] Selkie packaging

[Sebastian Kügler]

Hey all,

Over the past couple of weeks, I've re-written the webapp and action loading of 
Selkie. 

To remind you, Selkie is a standalone webapplication shell to run small, scripted 
specialized webapplications in their own process, their own window, menu entries and 
so on. It's basically a pluggable webkit view that can inject actions triggered via 
the toolbar for example into web pages. You run, for example "selkie gmail" and it 
shows a GMail window with buttons for "new email", for example. So instead of back, 
forward, home, refresh, ... you have actions that make sense  for the web application 
in question. Actions can also automatically be triggered when a page is loading, or a 
specific event occurs.

Web applications consist of metadata, stored in .desktop files, action files and 
scripts, javascript files. There's no compiled code in those webapps, which makes it 
easy to exchange them between platforms and share them over the web.

Up until now, I was using a two-layered plugin mechanism. selkie would query 
KServiceTrader for plugins available, and then query for actions belonging to that 
plugin. To make those web apps more self-contained, and be able to package them, I've 
had a closer look at Plasma::Package and imitated its package structure. In the end, 
I've decided to not use Plasma::Package directly since it's pretty specific for 
Plasma, and it was actually quite simple to implement something very similar, based 
on some of its code. So now, webapps are either in a small package (gmail.selkie) 
which contains a zippped up simple directory structure. The packaging is pretty much 
contained in Selkie::Package, so it's easily shared between selkie, selkie-remixer 
and selkiepkg.
This transition is not fully completed yet, but as I hack on it, it should become 
ready fairly quickly. (It's not really complicated code, but needs writing 
nevertheless.) "not fully complete" means that Selkie is currently a bit of a 
bastard, using both the directory-based webapp approach, and also the plugin loading 
one. Some code obviously needs to go :)

The package format looks like this:
luna.sebas(~/kdesvn/src/project-silk/selkie/packages/gmail): tree                              
|-- CMakeLists.txt
|-- actions
|   |-- silk-webapp-gmail-compose.desktop
|   |-- silk-webapp-gmail-hello.desktop
|   `-- silk-webapp-gmail-notify.desktop
|-- plugin.desktop
|-- scripts
|   `-- hello.js
`-- webapp.desktop

Obviously, actions go into the actions directory, scripts go into scripts/. Then 
there's a bit of metadata, currently scattered across two .desktop files which need 
consolidating. All in all quite simple but easily extensible.

One benefit we get from this is that we don't actually need to install the selkie 
webapp and have it indexed by ksycoca, but we can directly load it from either the 
zipped or unzipped package. We also don't need kdeinit running anymore (since the 
KServiceTrader queries are gone, making the whole thing much lighter in non-KDE 
environments without actually losing any functionality. Loading of the package is 
really, really fast here, I've timed it on my 4 year-old thinkpad at about 4-6msec on 
average with warm cache, so performance-wise, it's also not a problem for startup 
time. The selkie package are usually around a couple of kB (gmail.selkie is 3.9kB). 
Right now, they're installed unzipped, but I wonder if it won't be faster if we just 
store them zipped in the user's KDE data dir. Unzipping and loading takes about what 
really fast disks take for one seek, so as soon as the files belonging to the webapp 
are not cached and happen to not be in one block on the disk, unzipping and then 
opening the result will probably be faster.

If you install a selkie package, it will also end up in the menu, which is not the 
case for a .selkie package you open from disk. For installation, there are two 
mechanisms:

- cmake: There's a more or less generic selkie CMakeLists.txt which only needs a 
  project name and then installs all the files contained in the package's directory. 
  This should probably be put in a CMake function, but I'm not experienced enough 
  with cmake to know how to do that. For now, you can just use the CMakeLists.txt, 
  change its project name, and be done.

- selkiepkg: selkiepkg is a small binary program, say a dpkg or rpm for selkie 
  packages (but much lamer). It can take care of installing, removing, upgrading, 
  packaging and validating and listing installed packages. selkiepkg --help for more
  details.

I've also done some reorganisation of the codebase, it's now:
- selkie/selkie for the selkie shell
- selkie/remixer for the webappeditor and selkiepkg
- selkie/packages for various packages we already have

One current regression is that selkie test doesn't work. This is actually a bit more 
complex as it's a complete website locally installed. It's not really hard, I just 
didn't get to it yet.
Also, selkie-remixer is still work in progress and not yet usable for creating 
complete webapps (it works for editing existing ones though). selkie-remixer also 
needs some changes made for it to cope with the new packaging format, and then be 
able to manage them.

It would be good if people could look over this, especially the package structure and 
provide points for improvements. It's important the package format is good enough for 
what we need, so we don't need to change it in backwards-incompatible ways in the 
future.

Thanks for reading so far :)
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-silk/attachments/20100404/ae958b48/attachment.sig