[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    Re: [klik-devel] klik-devel Digest, Vol 16, Issue 4
From:       probono <probono () myrealbox ! com>
Date:       2007-08-02 15:33:12
Message-ID: 85d71c370708020833j40af9e1ftae3f1a7c5d11d7b2 () mail ! gmail ! com
[Download RAW message or body]

Hi all,

it's been a while and you might have been wondering what I was
doing... No, I haven't lost interest in klik at all. I've been
contemplating various options we could take for "klik2", the next
major version, and have been waiting until some key technologies for
"klik2" are ready and are widely available in disttributions.

That time is now. We have FUSE, and we have LSB3 compliance in most
mainstream distributions. In other words, we can now make serious
steps toward "klik2".

One key component of "klik2" will be an "application virtualization"
technology, something that takes the cmg and "blends" it into the /
filesystem, and that overlays another "layer" for write accesses.
We've seen quite a number of virtualization options (Discussion on
http://klik.atekon.de/wiki/index.php/Virtualization_Options). While
each one has its specific advantages and disadvantages, I would say
that "UnionFUSE" (as used by Lionel's "klikutils") currently offers
the approach that fits our requirements best at this time. Especially,
it works on a great number of distributions, and by now, FUSE is
present on most general purpose distributions.

Another key component of "klik2" is that it will strive to be as LSB3
compliant as possible. That also means that we drop the strict
requirement to use libstdc++5, which allows us to use debian sid,
Ubuntu, and other binaries. (Let's hope that libstdc++7 won't break
binary compatibility again.)

What is happening at the moment?

* Lionel is in the finishing touches to make fusecram and fuseiso
ready to roll.

* Jason has started work on a Python-based klik client. While I don't
understand much Python (yet), I realize that it's a very powerful
language. Since itdoesn't need to be compiled, it is ideal for
cross-distro usage.

What do we need to do next in order to make "klik2" a reality?

* We need discuss and agree on a recipe.xml format. "Old-style"
recipes have been shell scripts that include the logic for
downloading, unpacking and creating the cmg. We want to have this
logic as a generalized part of the client, so that the recipe.xml
itself will (in the easiest case) consist of little more than the
package URLs to be used as the ingredients. The question really is
whether we can use whatever ROX/0install's xml format has or whether
we need something new. (Discussion on
http://klik.atekon.de/wiki/index.php/Recipe_Files)

* We need to discuss and agree whether we want to go with Python for
the client. In addition of Jason's initial code, I had written a
little GUI app some time ago as well
(http://klik.atekon.de/wiki/index.php/Updater). With a GUI framework
that uses native widgets on all desktops, Python might also be the
answer for our *dialog woes. Also, it can easily parse XML and is well
extensible using APIs for next to anything.

* We need to "put together" all the great code we have, so that all
the pieces come together as one. Jason has set up a Subversion
repository on Google Code
(http://code.google.com/p/klikclient/source). Personally I don't know
how to use that yet, but if we agree to move all our development there
(FUSE, client, thumbnailers,...) it would certainly speed up the
remaining development process for "klik2". We need to elect a
Subversion "master". Volunteers, Jason? ;-)

* We should get a issue/wishlist/bugtracker.

* We should agree on a time in the week to hold regular meetings on
IRC. What about Sundays 9pm CEST?

Greetings,
probono
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel
[prev in list] [next in list] [prev in thread] [next in thread]