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

List:       klik-devel
Subject:    [klik-devel] Fwd: Re: Possible ideas for klik
From:       Lionel Tricon <lionel.tricon () free ! fr>
Date:       2007-08-07 17:35:25
Message-ID: 200708071935.26015.lionel.tricon () free ! fr
[Download RAW message or body]

To follow the thread.

ps : Maybe can we propose him to participate to the next irc developer 
meetings ?

["forwarded message" (message/rfc822)]

Return-Path: <lionel.tricon@free.fr>
Delivered-To: online.fr-lionel.tricon@free.fr
Received: (qmail 6598 invoked from network); 7 Aug 2007 17:32:47 -0000
Received: from 212.27.42.29 (HELO smtp3-g19.free.fr) (212.27.42.29)
  by mrelay5-2.free.fr with SMTP; 7 Aug 2007 17:32:47 -0000
Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp3-g19.free.fr (Postfix) with ESMTP id 444775A198;
	Tue,  7 Aug 2007 19:32:47 +0200 (CEST)
Received: from [192.168.0.15] (mil13-1-88-163-136-135.fbx.proxad.net \
[88.163.136.135])  by smtp3-g19.free.fr (Postfix) with ESMTP id F2C9C5A121;
	Tue,  7 Aug 2007 19:32:46 +0200 (CEST)
From: Lionel Tricon <lionel.tricon@free.fr>
To: Alexander Larsson <alexl@redhat.com>
Subject: Re: Possible ideas for klik
Date: Tue, 7 Aug 2007 19:32:40 +0200
User-Agent: KMail/1.9.7
Cc: k1pfeifle@gmx.net,
 lionel.tricon@free.fr
References: <1186499400.5412.10.camel@greebo> <46B89D54.7040607@free.fr> \
                <1186504448.5412.16.camel@greebo>
In-Reply-To: <1186504448.5412.16.camel@greebo>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200708071932.40416.lionel.tricon@free.fr>

On Tuesday 07 August 2007 18:34:08 Alexander Larsson wrote:
> On the other hand, there is no local installation needed for the
> runtime. Its not clear to me which is best. Its probably a case-by-case
> thing.

I agree that the fact that nothing need to be installed before is really, 
really, promising ! But with the solution (not perfect i know) based on a 
patched-fuse, we can also sandbox the application so all modifications can be 
redirected into a single directory. I fear that with your bundle that won't 
be possible. Correct me if i am wrong.

And you will have to modify the software like for klik1 no ? (relatives paths)

> Well. glick could easily be made into an installable package that you
> can easily use to make glick images, however that package would not be
> needed on the clients.

The klik2 approach, as for the actual one, will be to download a recipe to 
build the cmg file (ie. the application) on the client. So the possibility to 
make cmg images is necessary.

> For fuse modprobe. A correctly set up udev should handle that. It'll
> take some time, but soon every "modern" distro will have that. There is
> just to much things using it to not do that.

Well, we planned to build two kind of klik2 runtime : A clean one (rpm, deb) 
that will setup fuse correctly and a quick-and-dirty one with a modified and 
private fusermount binary that could set up fuse if needed on each run.

> For compression. Yes, glick currently does no compression. However, a
> move to cramfs for the filesystem image would add compression to
> everything but the glick code (which is about 50k).

I agree. And i am impressed for the size of the glick code which is very 
small !

> Heh. Well, another way might be to support a runtime optionally, but if
> its not installed fall back on the built-in fuse support. (i.e. more of
> a merging of the glick and the klik approach, and not just putting one
> in the other).

All ideas are welcome.
But your bundle seems very promising depending on how we can reuse it.

Lionel



_______________________________________________
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]