Re: [Chicken-users] Idea feedback

[john]

This is what I do now. I actually package Chicken for the mobile which
installs the shared library. I was looking at a cleaner separation so
one app remained C without FFI code (or knowledge of Chicken) the
other remained Chicken (with knowledge of D-Bus). The interface
between the two being D-Bus. I am quite possibly trying to over
engineer something here but interested in the alternatives to
embedding. I would like to tell John Doe, you write this C app that
talks to D-Bus. John Doe is happy as he knows how to talk to D-Bus
from his C app and has never heard of Chicken or Scheme or
s-expressions. John Doe does not need to care beyond that point how
the data is encoded/sent/decoded/received and can build his app the
way he knows how.

Regards,

John.

On 14/02/2008, Elf <address@hidden> wrote:
>
>
>
>  On Thu, 14 Feb 2008, john wrote:
>
>
> > Yes, I remember talk of dbus! Any progress Shawn?
>  >
>  > I am actually doing what you describe now and embedding Chicken to C
>  > to handle s-expressions and bit stuffing them (packedobjects). I was
>  > curious though to examine ways of removing the dependency of Chicken
>  > from the graphical client and using dbus to communicate with another
>  > entity that handles the s-expressions. Removing Chicken would simplify
>  > building the graphical client on the mobile. The problem is just moved
>  > to another place and hidden from C developers who could focus on the
>  > client. If that makes sense.
>  >
>  >
>
>
> whats wrong with simply including libchicken.so (built for whatever platform)
>  with the codeball for the graphical client?  wouldnt need to build chicken
>  again there and youd be simplifying interfaces and reducing dependencies...
>  with a little work, you could even write some code that only used the bits
>  of chicken you needed, compile that to a static lib, and send that, if
>  space is at an insane premium...
>
>
>  -elf
>