Re: Introspection API
- From: Matthias Clasen <mclasen redhat com>
- To: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Cc: gtk-devel-list gnome org, language-bindings gnome org, Colin Walters <walters verbum org>
- Subject: Re: Introspection API
- Date: Fri, 25 Feb 2005 10:38:14 -0500
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
> >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. 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 ?
] [Thread Prev