DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=myZLPlBqbe2XOR24yJiN46Qix4RVRiX+oRRdBBcipDWQeglqwPGk0o6RhYwpBiCm/P
         NQ4fNGW6LGJZ18qhF60xahEAMDdah6Nvs8oRS06GhNMBUuhZIKSlSAAjnm8HQLahNyBo
         ha8R4DO9Ow4a4FvNAbFGWxuJKPPZ5O8o0G2co=
Precedence: list
MIME-Version: 1.0
Date: Tue, 2 Mar 2010 08:40:46 +0100
Message-ID: <95408c821003012340w72402e30mbf177585e74bede7@mail.gmail.com>
Subject: [alpine-devel] apk-tools idea: runtime plugins
From: Natanael Copa <natanael.copa@gmail.com>
To: Alpine Developers <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset=ISO-8859-1

Other idea I have been thinking for some time: runtime plugins for apk-tools

What triggered this idea was that it would be nice to have a "real"
http/ftp downloader via curl or similar instead of fork/exec bb wget,
however, would not be nice to need libcurl in the initramfs image.

Some options:
We could have fetcher plugins. install /lib/apk/fetch_curl.so and
suddenly you have http and ftp support. Install /lib/apk/fetch_scp.so
and suddenly apk-tools understands scp:// repositories.

We could have applet plugins. Install /lib/apk/index.so and you get
'apk index' etc.

In future we could have /lib/apk/gtk-progress-bar.so etc...

Other option is that we could have only one plugin that have all the
"extended" stuff. So you have an apk-tools-base or similar, containing
only the basic functionallity, apk add, apk del and thats it. It could
use the busybox wget to fetch from http. Then you have another package
apk-tools-extras or similar that includes plugins for http download
via curl, includes the developer stuff like apk index etc.

In any case, it would be nice to be able have a framework for runtime plugins.

-- 
Natanael Copa


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---