DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=VTmydVjNxz9Y8Jl62dBiiKFTNXK0thrO6f+qidtiG9blQfgqQdPPtVUdFnbpQgKz+6
         qvR+JfbnszvJgodZyc5mNos4TlvZf2pemgpsUQRJ6rTP0WMWcCCvSlG1wbbF87Nzg+qm
         j+8bcE9+DQl66nDbSjKF/5hbdDqv7zgu+R25E=
Message-ID: <4B8D1D3F.4010102@gmail.com>
Date: Tue, 02 Mar 2010 08:14:23 -0600
From: Cameron Banta <cbanta@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091225 Lightning/1.0pre Thunderbird/3.0
Precedence: list
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Timo_Ter=E4s?= <timo.teras@iki.fi>
CC: Natanael Copa <natanael.copa@gmail.com>, 
 Alpine Developers <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] apk-tools idea: binding to other applications
 and languages
References: <95408c821003012321j22b36b8fk1130a838f32fa9b6@mail.gmail.com> <4B8CDDFE.2090202@iki.fi>
In-Reply-To: <4B8CDDFE.2090202@iki.fi>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 03/02/2010 03:44 AM, Timo Ter=E4s wrote:
> Natanael Copa wrote:
>> Som things I have been thinking of for some time.
>>
>> It would be nice to make apk-tools functions available from other
>> applications and higher level languages. The immedeate need I have is
>> a binding to the version compare functions from lua. In the longer run
>> it would be nice to be able to make a gui installer and have a nice
>> gui progress bar while installing. The point is that we will sooner or
>> later need to bind to apk from other applications.
>>
>> We have some alternatives:
>> 1. we can make a dynamic libapk.so and have the apk application link
>> to it and have the lua apk.so to link to it too. Less dupe of code.
>> 2. we can dup the code. A build target uses same code but builds a lua
>> apk.so or similar.
>> 3. we can have lua library fork/exec the current apk and parse the
>> output. I don't like this, specially not for sorting scripts that
>> needs compare version strings.
>>
>> When it comes to the initramfs installer, we already need libcrypto,
>> libz, libc and openssl (for encrypted apkovls) in the initramfs image
>> so adding another lib doesnt really matter. (we could make an initapk
>> tool which links libc and libapk statically but libcrypt and libc
>> dynamic)
>
> From size point of view, option 1 is best. Though, currently apk
> library will not be that large so option 2 is ok too. Option 3 is
> not a good idea from performance point of view.
>
> However 1&2 do require that we start to maintain some sort of
> stable API. At least for the high level stuff the lua code wants
> to do.
>

A couple thoughts on this.

I like how easy lua is to embed into the app itself with no external
dependencies. Because apk is very small to start with that will add
considerable size to the executable (100K-300K I think).
This would allow us to write even some core functionality of apk in lua.
I believe you can also compile lua scripts directly into the executable
- size is bigger, but makes for easier development and changes.
This also allows writing plugins directly in lua, and just dropping them
in some directory to extend the functionality of apk.

That's all a bit different than having an app use apk. I've used swig
(http://www.swig.org/) before, and I like how it can create bindings for
several languages (lua, python, perl, php, ruby, etc) from one swig
config file that basically defines the API. These bindings could all be
in their own apk packages and be depended upon by any apps that want to
use them. These bindings can be compiled into their .so files from the
same source files that apk is compiled from, so there wouldn't really be
much duplication of code.

There are other tools like swig out there, swig is just the only one
I've personally used before.

-Cameron


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---