Re: [Chicken-users] Idea feedback

[john]

Actually talking through this now I have just realised a major over
sight in my cunning plan! I would still need a structure to the
protocol over the D-BUS session and this would still need to be
handled from C. From my limited understanding of D-Bus it provides
mechanisms for structuring data that is binary encoded. I am not sure
if it handles complex nested structures and how much easier a D-Bus
programmer would find this approach! Oh well....it's good to talk!

Thanks,

John.

On 14/02/2008, john <address@hidden> wrote:
> 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
>  >
>