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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
