Re: Introspection API

[Matthias Clasen <mclasen redhat com>]

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. 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 ?

Matthias