So create another shared library which uses the Chicken shared library which then provides the clean API and hides other functionality away from the C app! You are right that does seem more straight forward then trying to separate and use inter-process communication. Oh well, I need to find another reason to play with D-Bus I guess.
Thanks Elf. On 15/02/2008, Elf <[EMAIL PROTECTED]> wrote: > > > On Thu, 14 Feb 2008, john 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. > > > > > way overengineered. just wrap the chicken lib in a nice api ... > then john doe doesnt need to know anything about chicken or that chicken is > there, hes just loading some shared lib that gives server access. > > > -elf > > > > > 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
