Re: GEP 8: Runtime Interface Data Generator For ORBit2

[Mark McLoughlin <mark skynet ie>]

Hi Alex,

On Wed, 25 Sep 2002, Alexander Larsson wrote:

> On Wed, 25 Sep 2002, Mark McLoughlin wrote:
>
> > Hey,
> > 	This GEP is a pretty straightforward "Here's what we need and
> > here's the implementation - any objections" type GEP. We'll see how it
> > pans out.
> >
> > 	http://developer.gnome.org/gep/gep-8.html
> >
> > 	Discussion is on orbit-list@gnome.org ...
>
> I don't know very much about ORBit2 (I'm not even subscribed to
> orbit-list), but this strikes me as suboptimal from a performance
> perspective. I can just see the profiles of apps starting up and parsing
> idl files for a long time.

	But this is for scripting bindings only. It basically
centralises the parsing of idl that these bindings does already. No
normal apps would even link to this library.

	And, obviously, for any production apps written using the
scripting bindings we'd recommend using the shared library typelibs.
This is just to enable people code using these scripting bindings to
continue just hacking their scripts and running it without a compile
step in between.

>
> I would much rather see a solution based on typelibs. And by typelibs I
> don't mean the current shared library thing, I mean architecture
> independent binary files that can be quickly mmaped and decoded by orbit.
> Much like the stuff XPCOM and COM uses[1].
>
> If the IDL compiler generated such typelibs, and there were some automake
> macros to easily install idl files and build typelibs in
> $datadir/orbit-typelibs, then they could be read by ORBit at runtime and
> we would get the same benefits as parsing the IDL files except at a much
> smaller startup cost.
>
> [1] http://www.mozilla.org/scriptable/typelib_file.html

	Sounds really intersting ... I'll look into that. But again,
generating this typelib every time the idl changes is still like a
compile step for a person hacking on a script ...

	Does that make sense ?

Good Luck,
Mark.