Re: Defs format and XML

[Mike Kestner <mkestner speakeasy net>]

On Mon, 2002-01-14 at 00:03, James Henstridge wrote:

> You say that an XML format was easier to use.  This is likely to be true 
> for any language where XML parsers are readily available (or come 
> standard), but s-expression parsers are not.  This probably covers 
> almost every language available today (except scheme/lisp which have 
> s-expression parsers built in :).

Yes, exactly.  I found myself writing my C# code generator in perl
because it seemed the best way to parse s-expressions.  By contrast, my
XML format is parsed for free using the standard C# class libraries. 
 
> It would be fairly easy to map the existing defs format to XML, and the 
> changes in my python code generator would be fairly localised (I already 
> went through the process once in the going from Havoc's version 2 format 
> to the current one).  I can't speak for other developers though (Ariel?, 
> Murray?).

My XML format is not just a remap of s-expressions to XML.  I can try to
define a DTD and post it for discussion if anyone's interested. In a
nutshell, it's a hierarchical format, organized with an <api> root
element, which contains <namespace> elements.  The types are children of
<namespace>.  <object> elements contain all the <field>, <property>,
<signal>, and <method> child elements pertaining to the type. This seems
an optimal situation for any object-oriented language binding that
contains a standard DOM parser.  
 
> You also said that the current defs format was missing some features 
> needed for the GTK# binding.  Was there any particular features you are 
> looking for?  If the problems can be identified, then hopefully we can 
> integrate the ideas into the defs spec.

The latest spec is not missing much. My statement was more related to
the available defs files, not the defs format.  I found myself writing
perl scripts to generate s-expr based defs for Callbacks/Function
pointer types, structures, signals, properties, etc... I even found some
enums missing from the files, although I'm sure that was just because
the files hadn't been regenerated in a while.  I figured that since I
was writing all these source parsing scripts, I might as well have them
produce a format that was easier for me to use in a C# based code
generator. A hierarchical XML doc seemed the obvious choice.

You once asked me why I needed all the struct definitions. One challenge
that may be unique for me with Gtk# is that I don't have access to the C
headers at compile time.  I suspect that most of the existing bindings
have some sort of compiled glue level access to the C headers, which
allows them to ignore things like structure types.  

In order for me to invoke a function, I need to declare a signature for
it and identify the dll that contains it.  For each parameter in the
signature, I have to either map it to an existing C# type and provide
marshaling code to the native type, or I have to define a new C# type
with marshaling attributes to utilize the built-in PInvoke marshaling
capabilities. 
 
> Please don't misinterpret this as a stake burning :)  I would just like 
> to see all LBs using the same formats/code where appropriate.

I agree that a common format is preferable. Before going into stealth
mode and reinventing this wheel, I invested considerable time in trying
to make the s-expr defs format work for Gtk#.  It was my intention to
come back and preach about XML's virtues after fully debugging the XML
format and source parser. I'm currently parsing up through gtk+, and
it's looking pretty good now. I haven't exercised all the elements with
my generator, though. Hopefully I'll have all the kinks worked out by
end of Jan.

Anyway, thanks for the note, and let me know if I can clarify any of the
above.  

Mike