designing lib API for use with various languages

ta0kira · 04-30-2007, 12:31 PM

I am writing a library with an internal language of C++ and a primary API in C. It is part of a networking application which will use asynchronous client-end communication. By this I mean the project will provide a lib for linking and dynamic loading by client programs which will que incoming transmissions for the client program. This allows the client program to run with a single thread (aside from what the library starts) and deal with incoming data as it gets to it. Responses should be assumed to be out of order and in various parts.

Each incoming transmission will contain numerous pieces of information such as ref#, request type, requestor, request data, error states, etc. I've managed to simplify the client API so that it will work with C by using structures and char*, but I don't know how well other languages capable of loading C libraries can deal with structs. I'd like to have an additional API for use by languages such as lisp and python (neither of which I know myself), but I'd like an alternative to a half-blind stack and single-attribute-per-call interface. Does anyone know of some alternatives? Thanks.
ta0kira

gearoid_murphy · 05-01-2007, 05:41 AM

hmmm, I'm not really sure, a cursory examination of the web hints at the possiblity of begin able to import c libraries into lisp in some form, I don't know if you as a programmer have to do anything to ease the migration process. Java does have mechanisms for accessing native code in its "natural" form, python is (as far as i'm aware) simply a collection of c modules so supporting that shouln't require anything extra.

Please explain what you mean by "half-blind stack" and "single-attribute-per-call" interface. I've never heard of these terms and google turns up nada.

ta0kira · 05-01-2007, 07:30 AM

Sorry, those are just my descriptions. I say "half-blind" because basically I'd be leaving the user to feel around one function call at a time and "single-attribute-per-call" because they would end up gaining a single attribute of a message each function call if I can't return a struct or pointer to one. For example, in C they could iterate through an array of responses and access each message via a struct pointer. Without structs they would have to manipulate an internal stack which they could not see and would require a different global function call for each attribute of a message they wish to access.

Code:

//an interface for C

typedef struct
{
    const char *message;
    const char *sender;
    unsigned int priority;
} message;

extern struct message *current_message();

Code:

//a struct-free interface

extern const char *current_message_text();
extern const char *current_message_sender();
extern unsigned int current_message_priority();

The difference might seem trivial, but when you extend that to 10 or more message attributes you have as many dynamic loads and casts to get right even for the smallest client program.

I did some research on both lisp and python before my first post and both only allow primative types (not all of them) and no structs as far as I can tell.
ta0kira

edit: I think I will need to build a separate library for non-C clients with quite a bit less functionality.