IDL language

[Havoc Pennington]

Hi,

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