GTT: Announce & Question

[Linas Vepstas]

On Wed, Sep 05, 2001 at 11:25:38AM -0400, Jonathan Blandford was heard to remark:
> IDL is the 

Comin back at you ...


I meant IDL in the general sense. There are idls for corba, for rpc.
ASN.1 is a kind of idl. As are DTD's and XML schemas. 

Each has a problem, a fault.
-- DTD's fail to have type information, making it hard to autogenerate
   a DTD-to-C stub generator.

-- XML Schemas, as far as I can tell, were invented to fix the DTD type
   problem.  However, the spec is immature, constantly changing,
   politicized, and lacks good/stable/complete/debugged free 
   implementations.

-- ASN.1 seems to be excellent, but lacks acceptance & understanding 
   outside of a very small circle.  Ergo poor tool set.
   
-- Corba IDL's tend to be specific to corba, and fail to deal with XML.

-- RPC IDL's look a little bit promising, in that we have XML-RPC.
   So I presume that means I can write a standard rpc IDL, have it
   autogenerate C stubs for me, and also autogenerate code that 
   will put XML on the wire.

   Unfortunately, rpc-xml doesn't seem to be designed for storage 
   as a file-format.  The way I like to look at XML in files is as
   a kind of kind of 'persistant object'.   I don't care too much
   about the details of the file format, I just want to recreate
   the same instance of an object at some later date, when I start the
   application again.

   XML-RPC has this ability, but its for recreating the object at a 
   different place in space, not at a different place in time.

-- The g-wrap IDL. Its specific to scheme, and deals only with
   scheme-to-C and back.  It doesn't do XML or other languages.
   It doesn't deal with the network or file-format issues.

-- SWIG.  Doesn't use an IDL per-se, it 'guesses' the IDL by looking
   at C header files.  This guessing leaves it open to vulnerabilites,
   making it inappropriate for either XML or rpc/corba work.

-- 'object introspection'.  Great if you're programming in scheme, 
   Java, or microsoft .net C#.   Up a creek without an IDL if you're
   programming in C or C++.  (With object introspection, the object
   knows about what it is, and therefore can be it's own IDL.)

> > Here's what I really want these days:  an IDL compiler that can read my
> > IDL, and auto-generate XML readers and writers.   
> 
> IDL isn't a file format here.  What you can do is define an interface
> that describes the data, and pass it across directly

IDL's generically define interfaces.  Once you've defined an interface,
you can do three things:
1) create language bindings.
2) teleport objects across the net (a la rpc or corba)
3) define a persistant-object-storage scheme (e.g. xml for a file
   format). (sql is harder, there are deeper issues).

> > (I recently wrote xml for gtt, and it is very very repetitive
> > cut-n-paste, and should really have been auto-gened from an IDL)
> 
> Every time I write something that reads xml, I come to this conclusion.
> I'm not sure what such a thing would look like.

It would look like an IDL, or a DTD, where you presss a button, and 
bingo, you've autogenerated code that reads and writes XML that 
exactly corresponds to saving and restoring the C/C_++/whetever object.

Technically, its not really hard to do this.  You are probably smart
enough to do a cheap hack to do this in a few weeks to a few months.

The problem is, unless its integrated into the grander scheme of things, 
it will remain just another hack.

--linas