IDL language

[Mark Doffman]

Hi,

I'm afraid I don't understand the point of the typelib.

In CORBA there were fixed mappings between the IDL and any particular
language interface. It was horrible. People wrote programatic interfaces
and expected them to work over-the-wire. It did have a few upsides
though. One of which was that in a dynamic language you could import an
IDL file or typelib as-if it were a language module. All the information
to generate bindings was there.

I don't see how the typelib helps anyone. To make the typelib useful for
dynamic languages you would need to put lots of information in it and
re-create the corba situation, at least for when you are importing the
typelib.

If that is useful to people working in Python, JS, Ruby then great. I'd
just prefer to staticly generate my bindings, even in Python, to gain
some more flexibility.

Either way, the typelib seems to me to be a great leap forward,
something to do long after a 'Base' IDL has been completed. Perhaps a
'Bindings' IDL could be written specifically for creating the typelibs,
making it well suited to creating great interfaces in Ruby, Python & JS.

> On Fri, May 8, 2009 at 8:23 PM, David Zeuthen <david at fubar.dk> wrote:
>> Well, good luck using the NetworkManager, Telepathy and DeviceKit-disks
>> and lots of other APIs from gjs then. Because all these APIs already (or
>> will in the future, in the case of DeviceKit-disks) use a{sv} for things
>> where you'd normally use a struct. Except for very simple stuff of
>> course.
> 
> It works fine, already using all of NetworkManager for example. Why
> wouldn't it work? There's no need to generate code if you don't have
> static type checking.
> You're misinterpreting something I wrote.
> 
> In JS a{sv} is really the "normal" and best type. The somewhat pesky
> type is an actual struct (a tuple), which I think in many cases with
> dbus, isn't a great idea to use. a{sv} maps to most languages better.
> A dbus struct in gjs has to become a heterogeneous array or the like,
> which can be used, but is a bit unnatural.
> 
> gjs can deal with whatever dbus APIs, it just doesn't _need_ a typelib
> to do so in many cases, and it never needs (statically) generated code
> because in JS anything you could generate at build time can also be
> generated at runtime.
> 
> On the "callee" side you pretty much never need a typelib because it
> can just accept any workable type; it doesn't matter what sort of
> integer the caller provides, for example.
> 
> On the "caller" side when talking to a non-JS peer, you sometimes need
> a typelib to force the right size integer, or similar cases. When
> going JS-to-JS, it never matters.
> 
>> This is simply because these D-Bus services don't want to lock the API
>> down, who knows, maybe in the case of ATA SMART or Filesystems we
>> pretend to support we need to add some field somewhere in the future
>> (very likely).
>>
>> You may not like this, but this is just the harsh reality of how people
>> use D-Bus. Do you think this is _wrong_?
> 
> You aren't understanding what I'm telling you. I don't think I said
> anything related to adding fields.
> 
> What I was saying, though, is that there's no reason to embed the
> struct name on the wire. Just pass a{sv} and document (or annotate in
> machine-readable form) what the fields are.
> 
>> That said, I'm not sure why it's not possible to generate JS code that
>> unpacks said a{sv} and presents you with a struct-like object with
>> getters and setters.
> 
> This is a no-op in JavaScript, because objects are just hash tables to
> begin with. There is no difference between:
> 
>    myDict['abc']
> 
> and
> 
>    myDict.abc
> 
> In JS, those are just alternate syntaxes for exactly the same thing.
> 
> The generated code would not give you anything *because there are no
> static types*; so the generated code does not add type safety, or
> change the syntax an application would use in any way.
> 
> Well, not to go on too much of a JavaScript tangent, but it doesn't
> have *dynamic* types either. It has a few built in types (Number,
> Date, Object, String, etc.) and you cannot implement new types in
> JavaScript; it doesn't have classes. So you can't even generate
> classes at runtime, in order to get type errors at runtime. The only
> errors are duck-type errors: "does not quack like duck"
> 
> Here's why JavaScript is sort of relevant: on the wire, dbus is
> exactly like JavaScript. It doesn't have classes, it just has data; it
> only has duck types. And, in my view, this is inherently true of all
> IPC, because in the end, you do not have "stuff I got off a socket" at
> compile time. It has to be runtime-checked for quackiness.
> 
>> I'm not opposed to translating IDL to XML but the output is going to
>> look just as ugly (actually uglier) as the hand-written dialects that I
>> posted links to elsewhere.
>>
>> E.g. you need a way to represent struct, dynamic_struct, enum and what
>> not if you don't want to throw away information and leave API consumers
>> looking elsewhere for what the heck the a{sv} variable of the week
>> means.
> 
> What's actually _in_ the typelib is a separate issue from the syntax.
> 
> Don't see how changing the syntax makes struct, dynstruct, enum, etc.
> more or less good.
> 
>> You'd also need to get everyone already invested in D-Bus introspection
>> XML to agree with these extensions.
> 
> You have to get everyone to agree on what's in the IDL also, if you're
> saying it's some kind of interoperability format.
> 
>> Sure, both things are feasible, just not sure it's worth it. More
>> importantly, what's the _point_ in such an exercise?
> 
>  * all (or all important) languages have an XML parser already
>  * many bindings already have parsers for our DTD specifically using
>     those XML parsers
>  * people are already installing the XML format
>  * it is primarily a machine-readable format
>  * for many of us, IDL isn't an improvement, because more language-native
>    solutions (with possible dbus-specific annotations) are a nicer approach.
>    Some languages such as Java and C# even have annotation support to
>    avoid "magic comments"
> 
>> Any exactly why wouldn't I just look at the IDL instead?
> 
> Because people didn't write the IDL, they wrote some other format,
> then converted it to an XML typelib.
> 
>> And if this
>> would ever work, then the XML files in /usr/share/dbus-1/interfaces
>> would look different from what's on the wire because they would need to
>> contain more information than what you transmit on the wire.
> 
> You're mixing up a bunch of different arguments. The information in
> the typelib is a different discussion from the syntax of the typelib,
> which is a different discussion from what syntax or language the
> typelib is generated from.
> 
> Extending the XML makes total sense, building on lots of ad hoc
> extensions people are already doing.
> 
> Allowing writing type information in IDL, which gets
> converted/installed as XML, makes total sense.
> 
> Changing the interoperable typelib format to IDL when it's already
> XML, and XML has nice advantages, does not make sense.
> 
> Havoc

Thanks

Mark