On Fri, 2005-02-25 at 10:38 -0500, Matthias Clasen wrote: >On Fri, 2005-02-25 at 10:58 +0000, Gustavo J. A. M. Carneiro wrote: >> On Thu, 2005-02-24 at 18:16 -0500, Colin Walters wrote: >> >On Thu, 2005-02-24 at 20:52 +0000, Gustavo J. A. M. Carneiro wrote: >> >>On Thu, 2005-02-24 at 15:20 -0500, Matthias Clasen wrote: >> >>>I have written up a draft spec for the format of the binary metadata >> >>>to back up the repository api which I posted earlier. I hope to have >> >>>some initial code implementing both of these soon. >> >>> >> >>>Comments highly appreciated, >> >> >> >> OK, I probably missed something but, exactly how are language bindings >> >>supposed to get the actual API function pointers? All I can see is >> >>function name. Should we use dlsym() (or glib equivalent abstraction)? >> > >> >c_name: The symbol which can be used to obtain the function pointer with dlsym(). >> > >> >So yes. >> >> Right, I did miss that. I just read "in diagonal"... >> >> > >> >> Once we get the function pointer, are we supposed to use libffi to >> >>call the function with the actual parameters? >> > >> >Hmm. That is a problem. Perhaps we could provide a way to easily >> >generate marshallers for functions in the introspection data on the >> >client end. It's a little unclear to me how this would integrate into >> >compilation. >> > >> >I guess languages like Java/C# will already be using libffi or >> >equivalent and so this won't be an issue. >> >> I'm not saying libffi is bad, if we have computer generated prototype >> descriptions. Manually using libffi is more of a problem due to the >> human tendency to make mistakes... >> >> Another concern about libffi is portability. But I looked at the home >> page and it seems to be fairly portable, so event that may not be much >> of a problem. >> >> I just wanted these things to be clear. No point in agreeing on >> high-level interfaces if we can't get lower-level details to work. > >Is using libffi or something similar a problem ? > >I'm not a language binding expert, therefore I just included what is >provided by the .defs plus some obvious additions. If you call this an *introspection* API, it means things are to be done at runtime. The way the .defs are used in pygtk is to generate compile-time wrappers. This has proved not to be very effective, so the idea is to move away from compile-time wrappers and do everything like we do with signals and properties, at run-time. > Should we make the >introspection api depend on libffi and offer some form of call-by-name >interface + the ability to register type conversion functions ? How >would such an api look like ? Better not to create such an API, I think. It would always be very much language specific. Let each binding do its own thing. Unless, and this is what I thought initially that would be done, we have an API to call functions using function name and GValue's. For example. gboolean g_call_function(const char *name, GValueArray *parameters, GValue *ret_val); /* returns FALSE if function failed */ This would be nice as it would avoid libffi altogether, at least from the bindings side. But the glib introspection code would probably have to do GValue conversion itself and use libffi anyway, unless all API functions are properly registered like properties and signals are, which I do not see as happening any time soon, honestly. Regards. -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature