GTT: Announce & Question

[Linas Vepstas]

On Wed, Sep 05, 2001 at 02:56:06PM -0400, Jonathan Blandford was heard to remark:
> For GNOME, we use CORBA for 1 and 2, and have don't really have a great
> option for 3.  I think most applications use libxml directly with a
> DTD.  

well, DTD's don't have type info, so they're kinda useless.

> Additionally, bonobo has a mechanism for storing CORBA_any's
> straight to disk.

Hmmmm.

> > > > (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.
> 
> That would be really nice.  One problem of doing this in a generic sense
> is that to really do it write requires a lot of the complexity that
> exists in libxml (such as type checking, value checking, mapping complex
> structs to xml).  

Nahh. First, you'd probably build it on top of libxml anyway, instead
of a replacement.

Next, this is where IDL's come in. They define the type, the value.  
They define the complex structs.  

I started writing a DTD-to-C++ stub generator for gnucash to support
OFX, (its in the experimental directory somewhere), before I realized
how b0rken DTD's were, and how a compile-time thing isn't what I wanted
anyway.  (Dynamic, 'any', runtime IDL assembly is a lot nicer).

(it worked ... parsing the ofx dtd auto-generated about 20 KLOC of C++
that I beleive compiled without errors. Yes, that's twenty thousand
lines of *stubs*. You get to add the actual *function*)

(libglade-xml is an example of how a run-time interface definition
is nicer than a compiled-in compile-time, traditional glade stub 
interface is).

> Parsing C typedefs is hardly a walk in the park.  

swig already does this, and does it well. No need to reinvent the wheel.
Besides, this is why you have an IDL in the first place.

The point being that C structs may have 'private' members that should 
*not* be saved/restored.  Only the 'public' interface needs be.

> I have a bad feeling that the generic infastructure would be as painful as
> the specific one.

No no, not at all. This is why g-wrap exists. It was easier to solve
the generic problem than the specific one.  I did a similar stunt 
with m4 macros in the sql backend.  300 lines of m4 auto-gen about 
2KLOC of tedious sql code.  (although I had to write an addtional 200 loc 
of m4 because there isn't any existing generic idl-like parser for m4).

what's painful is writing all these half-assed, semi-maintainable hacks
(such as my sql m4 macors), when it would be so much better if there
was one single generic, maintained sourceforge/gnome project that
everyone could use.  Instead of reinventing the wheel each time.

> Indeed.  It's not clear that the current mechanism is a hack; just
> tedious.

Umm, isn't there some biblical quote about camels and laziness in a 
programmer being a virtue? 

Speaking of which, maybe my problem is that I keep hoping/asking that
someone else will scratch my itches ....

--linas