~alpine/devel

2 2

[alpine-devel] apk-tools idea: runtime plugins

Details
Message ID
<95408c821003012340w72402e30mbf177585e74bede7@mail.gmail.com>
Sender timestamp
1267515646
DKIM signature
missing
Download raw message
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
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4B8CDE8F.2030703@iki.fi>
In-Reply-To
<95408c821003012340w72402e30mbf177585e74bede7@mail.gmail.com> (view parent)
Sender timestamp
1267523215
DKIM signature
missing
Download raw message
Natanael Copa wrote:
> 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.

Might be an idea. However, I'm not currently sure what extra benefit
we get from using libcurl or wget. Splitting the applets to separate
modules might be useful though.

> In any case, it would be nice to be able have a framework for runtime plugins.

Yes, the more modular code we do, the easier it is to extend it later.

Patches are welcome :)

- Timo



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Nathan Angelacos <nangel@nothome.org>
Details
Message ID
<4B946547.7090100@nothome.org>
In-Reply-To
<4B8CDE8F.2030703@iki.fi> (view parent)
Sender timestamp
1268016455
DKIM signature
missing
Download raw message
On 3/2/10 4:46 AM, Timo Teräs wrote:
> Natanael Copa wrote:
>> 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.
>>

Does the extra functionality outweigh the complexity?

apk is still relatively simple.  simple is good.

>> 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.
>
> Might be an idea. However, I'm not currently sure what extra benefit
> we get from using libcurl or wget. Splitting the applets to separate
> modules might be useful though.
>
>> In any case, it would be nice to be able have a framework for runtime
>> plugins.
>
> Yes, the more modular code we do, the easier it is to extend it later.
>
> Patches are welcome :)
>
> - Timo

ok.. refactoring apk so that plugins are easier is one thing... but 
still not convinced on the value vs effort(code+bug reports) on the 
plugin part.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)