GLib plans for the next cycle

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mark Doffman
Hi Mikkel

>
>> <SNIP>
>>
>>
>> Methods are declared by:
>>
>> method methodName {
>>        enumName anenum;
>> } reply {
>>        structName astruct;
>> } throws (ErrorOne, ErrorTwo);
>>
>
> If you are so keen on clearing out that this is not really a 'method' then
> why is it declared as such? Why not call it 'message'?

I have misgivings about calling it 'method'. The problem is that
'message' also refers to 'signal' and 'error'. 'method' is the name
given to these types of messages in the D-Bus spec, so it seems
reasonable for it to be the name in the IDL.

>
> Both the throws and reply clauses are optional, but if a method does not
>> have a reply it should not have a throws clause.
>>
>
> Is this a limitation of DBus or you spec or the IDL? It seems odd that
> methodTakingEnum(in i myEnum) can not return a DBus error if myEnum is out
> of range...

Not sure. I believe that its really a limitation of the libdbus
bindings. There is not an easy way to have an async method sent and
register a handler for an Error message. Good point though. There isn't
anything against it in the D-Bus specification so I retract that
statement. It now becomes:

Methods can have an optional reply or throws clause.

>
> And also; can we not call it something other than didl? It is impossible to
> google as there are already tonnes of didls - not to mention the infamous
> Diddl mouse that Google is pretty convinced that I am really wanting to
> search for (which may or may not be correct, but please don't go there)  :-)

Point taken, name will be changed to something more googleable. Messdl?
(Message description language) Something more inventive anyone?

>
> Anyways I am really glad that someone is looking into this, but I also hope
> that we end up with only one IDL and not N > 1.
>

Thanks

Mark
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mark Doffman
In reply to this post by Mark Doffman
Hello all,

There were some glaring errors in the example IDL I provided.

> On to the syntax:
>
> My idea for the IDL syntax is to remain close to the 'C' family of
> languages, and is most places to C#.
>
> Elements can be namespaced using:
>
> namespace {
>
> }
>

Should be:

namespace org.freedesktop {

}

> But this should not necessarily translate into a D-Bus interface.
>
> Interfaces are created by:
>
> interface {
>
> }

Should be:

interface atspi2 {

}

Also I left out the possibility of properties. Properites do not really
fit with my idea for this IDL. They are too high-level. But as they are
included in Qt, Telepathy and EggDBus they have to exist.

readable writable property PropName {
        AStruct one;
        uint32 two;
}

readable writable are optional. Default is to both.

Properties are difficult because the method of transport for the
properties is unknown. (Telepathy uses a different properties interface
I believe) The default should be org.freedesktop.DBus.Properties but
perhaps there needs to be an extension to specify the underlying interface.

Thanks

Mark
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
In reply to this post by Mark Doffman
Hi,

On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
<[hidden email]> wrote:
> Both the throws and reply clauses are optional, but if a method does not
> have a reply it should not have a throws clause.

This is perhaps a misunderstanding. All methods have replies (in the
wire protocol). You may choose to ignore or not wait for the reply, if
you don't need confirmation that the method message was received and
handled.

This should *not* be in an interface description. For a given method,
one client can call it and wait for reply, and another client can call
it and ignore the reply. This is just up to the method caller whether
to do this. But all methods can be invoked in both ways.

Whether to block for reply is an example of a hint needed for static
code generation, that is not part of the interface description. I
would recommend handling this as a command line switch or similar on
the code generation tool.

There is a flag on messages that senders can set to indicate they do
not intend to wait for a reply; this is just an optimization. But note
it is per-message, not per-message-type.

> Probably the most controversial element of this syntax is that methods
> are not described using normal method syntax. This is to make utterly
> explicit that D-Bus methods are nothing more than a message type. And
> D-Bus nothing more than a message passing system. This IDL is describing
> message types, not function call types. When I started using D-Bus the
> notation of <method> <arg/> </method> fooled me into thinking that D-Bus
> methods were function calls, and as such synchronous. I want no-one new
> to D-Bus to make that mistake again.

This seems like a misunderstanding also. How do you think CORBA works?
It is the same on the wire; it sends some stuff over the socket to
make a method call, and unless you specify "oneway" (which is brokenly
in the IDL, rather than the code generator) it blocks and waits to
know if the method was processed. dbus is exactly the same.

Whether to block is just a matter of whether you block. You can block
or not. If you block, you wait to get an "ack" back, possibly with
return values in it. If you don't block, then you fire-and-forget.

*libdbus* which is one dbus implementation, encourages you not to
block, because I consider that more correct and in any case very
useful. But it does have APIs suitable for blocking as well, like
dbus_connection_send_with_reply_and_block().

Anyway, I think there is no difference between method calls and
message passing. The only difference is in whether the client side API
is made to look just like a native object. But that's totally
orthogonal to the IDL and to the wire protocol.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

DBus IDL (Was Re: GLib plans for the next cycle)

Mark Doffman
Hi Havoc,

Thanks for the reply. I have also changed the subject of this which I
should have done in the initial e-mail.

> Hi,
>
> On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
> <[hidden email]> wrote:
>> Both the throws and reply clauses are optional, but if a method does not
>> have a reply it should not have a throws clause.
>
> This is perhaps a misunderstanding. All methods have replies (in the
> wire protocol). You may choose to ignore or not wait for the reply, if
> you don't need confirmation that the method message was received and
> handled.
>
> This should *not* be in an interface description. For a given method,
> one client can call it and wait for reply, and another client can call
> it and ignore the reply. This is just up to the method caller whether
> to do this. But all methods can be invoked in both ways.
>
> Whether to block for reply is an example of a hint needed for static
> code generation, that is not part of the interface description. I
> would recommend handling this as a command line switch or similar on
> the code generation tool.
>
> There is a flag on messages that senders can set to indicate they do
> not intend to wait for a reply; this is just an optimization. But note
> it is per-message, not per-message-type.

I take your points completely. Details of waiting for a reply or not
should not be in the interface description. Details of whether to set a
method call as 'no-reply' should not be in this IDL.

When describing this IDL, and in the design, I imagined that all methods
that did not specify a reply should be mapped to a "no-reply" call and
all methods that did specify a reply should generally be sent
asynchronously, but that this would be down to the binding. I now
realize that this is wrong, all notions of how the message are sent
should be binding specific, and provided in hints elsewhere if necessary.

The IDL should only specify the format of the message and optionally the
format of the reply. If no reply format is specified the reply is
assumed empty.

>
>> Probably the most controversial element of this syntax is that methods
>> are not described using normal method syntax. This is to make utterly
>> explicit that D-Bus methods are nothing more than a message type. And
>> D-Bus nothing more than a message passing system. This IDL is describing
>> message types, not function call types. When I started using D-Bus the
>> notation of <method> <arg/> </method> fooled me into thinking that D-Bus
>> methods were function calls, and as such synchronous. I want no-one new
>> to D-Bus to make that mistake again.
>
> This seems like a misunderstanding also. How do you think CORBA works?
> It is the same on the wire; it sends some stuff over the socket to
> make a method call, and unless you specify "oneway" (which is brokenly
> in the IDL, rather than the code generator) it blocks and waits to
> know if the method was processed. dbus is exactly the same.
>
> Whether to block is just a matter of whether you block. You can block
> or not. If you block, you wait to get an "ack" back, possibly with
> return values in it. If you don't block, then you fire-and-forget.
>
> *libdbus* which is one dbus implementation, encourages you not to
> block, because I consider that more correct and in any case very
> useful. But it does have APIs suitable for blocking as well, like
> dbus_connection_send_with_reply_and_block().
>
> Anyway, I think there is no difference between method calls and
> message passing. The only difference is in whether the client side API
> is made to look just like a native object. But that's totally
> orthogonal to the IDL and to the wire protocol.

I understand that there is no difference on-the-wire between a
function-call and message passing. The difference is in peoples
perceptions and expectations.

When I read CORBA IDL and see:

int AFunction (int, int);

Because of the connotations provided to me by years of procedural
languages I expect this function call to be synchronous. I hope to break
these perceptions by providing a message-based IDL.

Thanks

Mark

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Colin Walters
In reply to this post by Mark Doffman
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
<[hidden email]> wrote:
> Hello Everyone,

I think the DBus list would be interested too.

> I feel that the D-Bus introspection XML is used badly. For writing a
> D-Bus specification there is too little information to understand a
> protocol. Although numerous extensions have been made (Qt, EggDBus,
> Telepathy) these are all incompatible.

Right.

> The immediate criticism I imagine I will face when creating a D-Bus IDL
> is that we are re-creating CORBA.

Well, CORBA is a lot of things.  Some good[1], some bad[2], and some
completely insane[3].

> This is not the case. The D-Bus IDL
> has NO defined mapping into language bindings. They serve only to
> provide readable documentation for a D-Bus protocol. They may also help
> language bindings, providing hints as to how the protocol should be mapped.

A key question to consider is - do you plan for software to install
this IDL into a well-known location?  Should the ConsoleKit-devel
package come with IDL instead of the dbus-glib XML in
/usr/share/dbus-1/interfaces it has now?

If not, why not?  If so, then I think it makes sense to consider using
it for at least statically typed bindings.  In other words the goal
should be to replace the various XML formats as much as possible.

Also, some prior work:

http://lists.freedesktop.org/archives/dbus/2004-March/000817.html


[1] The IDL was generally OK
[2] Bindings weren't very good, though I guess we share this problem with DBus
[3] Trying to unify in-process invocation vs out of process vs on the network
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: DBus IDL (Was Re: GLib plans for the next cycle)

Brian J. Tarricone
In reply to this post by Mark Doffman
Mark Doffman wrote:

> I understand that there is no difference on-the-wire between a
> function-call and message passing. The difference is in peoples
> perceptions and expectations.
>
> When I read CORBA IDL and see:
>
> int AFunction (int, int);
>
> Because of the connotations provided to me by years of procedural
> languages I expect this function call to be synchronous. I hope to break
> these perceptions by providing a message-based IDL.

I don't have this perception; I think you're mistaking your own
perceptions for the majority's.

One of the huge benefits of this entire exercise is to "hide" dbus calls
and make them look like methods on an object.  If you're going to avoid
calling dbus methods "methods," then I fail to see the point.

Whether or not the object is local (in-process) or not is irrelevant.
Whether or not the method call is sync or async is also irrelevant.
It's a method call, pure and simple.  DBus itself even calls them method
calls.  All you're doing by avoiding that in the IDL is making us learn
and remember yet another confusing and incompatible syntax.

I ask you to *please* reconsider not using some normal method-call
syntax for the IDL.  There's really no reason to do otherwise.  If there
really is a perception problem, people need to fix that on their own.

        -brian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: DBus IDL (Was Re: GLib plans for the next cycle)

Rob Taylor-3
Brian J. Tarricone wrote:

> Mark Doffman wrote:
>
>> I understand that there is no difference on-the-wire between a
>> function-call and message passing. The difference is in peoples
>> perceptions and expectations.
>>
>> When I read CORBA IDL and see:
>>
>> int AFunction (int, int);
>>
>> Because of the connotations provided to me by years of procedural
>> languages I expect this function call to be synchronous. I hope to break
>> these perceptions by providing a message-based IDL.
>
> I don't have this perception; I think you're mistaking your own
> perceptions for the majority's.
>
> One of the huge benefits of this entire exercise is to "hide" dbus calls
> and make them look like methods on an object.  If you're going to avoid
> calling dbus methods "methods," then I fail to see the point.


I think you're confusing describing the wire format of a message bus
protocol with language bindings. Personally I would like to avoid that
confusion which caused a good few problems in the CORBA days.

> Whether or not the object is local (in-process) or not is irrelevant.
> Whether or not the method call is sync or async is also irrelevant. It's
> a method call, pure and simple.  DBus itself even calls them method
> calls.  All you're doing by avoiding that in the IDL is making us learn
> and remember yet another confusing and incompatible syntax.

Wow. No.

That was the main insanity of CORBA. Hiding that something is IPC
results in you thinking things are working one way when in fact they're
working completely differently and subject to a load of unexpected
failure modes.

Other things to consider here is that hiding IPC can also result in
hugely inefficient IPC because you end up designing a pretty API rather
than efficient IPC.

I could rant at length here about the various benefits of CORBA vs
message bus. But suffice to say hiding that there's a message bus means
you end up with CORBA again and all the attendant problems.

> I ask you to *please* reconsider not using some normal method-call
> syntax for the IDL.  There's really no reason to do otherwise.  If there
> really is a perception problem, people need to fix that on their own.

Thanks,
Rob

>     -brian
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


--
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: DBus IDL (Was Re: GLib plans for the next cycle)

Mark Doffman
In reply to this post by Brian J. Tarricone
Hi Brian,

Thanks for your reply,

>> I understand that there is no difference on-the-wire between a
>> function-call and message passing. The difference is in peoples
>> perceptions and expectations.
>>
>> When I read CORBA IDL and see:
>>
>> int AFunction (int, int);
>>
>> Because of the connotations provided to me by years of procedural
>> languages I expect this function call to be synchronous. I hope to break
>> these perceptions by providing a message-based IDL.
>
> I don't have this perception; I think you're mistaking your own
> perceptions for the majority's.

Possibly. I can only go on what I've experienced though. For example the
function supplied above when written in CORBA IDL DOES map to a
synchronous function call. To make the above call async one has to use
the 'oneway' modifier. So the people that wrote the CORBA IDL had the
same expectations as me.

>
> One of the huge benefits of this entire exercise is to "hide" dbus calls
> and make them look like methods on an object.  If you're going to avoid
> calling dbus methods "methods," then I fail to see the point.

Its not my intention to 'hide' dbus calls. Although one could write an
IDL and IPC libraries like this (CORBA did something similar) I think
its better to write a language that just describes message formats
specific to D-Bus. You might not have use for it, but I think it will be
very useful to a project I am working on.

>
> Whether or not the object is local (in-process) or not is irrelevant.

Really don't agree.

> Whether or not the method call is sync or async is also irrelevant. It's
> a method call, pure and simple.  DBus itself even calls them method
> calls.  All you're doing by avoiding that in the IDL is making us learn
> and remember yet another confusing and incompatible syntax.

I don't think its a good idea to avoid calling the messages 'methods'.
Its what the D-Bus specification calls them, so I'll stick with it.

>
> I ask you to *please* reconsider not using some normal method-call
> syntax for the IDL.  There's really no reason to do otherwise.  If there
> really is a perception problem, people need to fix that on their own.

I'm fairly sure that what I'm doing here is correct. But I'll admit it
does move away from the syntax comfort zone. There really isn't that
much to learn with an IDL, its not a programming language, so people
should be able to pick up the one moderately new thing fairly quickly.

>
>     -brian
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Thanks

Mark

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: DBus IDL (Was Re: GLib plans for the next cycle)

Alexander Larsson
In reply to this post by Rob Taylor-3
On Mon, 2009-03-02 at 22:26 +0000, Rob Taylor wrote:

> Brian J. Tarricone wrote:
> > Whether or not the object is local (in-process) or not is irrelevant.
> > Whether or not the method call is sync or async is also irrelevant. It's
> > a method call, pure and simple.  DBus itself even calls them method
> > calls.  All you're doing by avoiding that in the IDL is making us learn
> > and remember yet another confusing and incompatible syntax.
>
> Wow. No.
>
> That was the main insanity of CORBA. Hiding that something is IPC
> results in you thinking things are working one way when in fact they're
> working completely differently and subject to a load of unexpected
> failure modes.
>
> Other things to consider here is that hiding IPC can also result in
> hugely inefficient IPC because you end up designing a pretty API rather
> than efficient IPC.
>
> I could rant at length here about the various benefits of CORBA vs
> message bus. But suffice to say hiding that there's a message bus means
> you end up with CORBA again and all the attendant problems.

I very very much agree. And I had to fight these CORBA problems for many
years maintaining a bonobo based application. Please learn from history
and don't fuck up our platform again.

This should be required reading for everyone that ever touches IPC:
http://research.sun.com/techrep/1994/abstract-29.html

Its as true today as it was when it was written (1994!).

This is also a nice starting point for similar ideas:
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: DBus IDL (Was Re: GLib plans for the next cycle)

Brian J. Tarricone
On Tue, 03 Mar 2009 10:55:33 +0100 Alexander Larsson wrote:

> On Mon, 2009-03-02 at 22:26 +0000, Rob Taylor wrote:
> > Brian J. Tarricone wrote:
> > > Whether or not the object is local (in-process) or not is
> > > irrelevant. Whether or not the method call is sync or async is
> > > also irrelevant. It's a method call, pure and simple.  DBus
> > > itself even calls them method calls.  All you're doing by
> > > avoiding that in the IDL is making us learn and remember yet
> > > another confusing and incompatible syntax.
> >
> > Wow. No.
> >
> > That was the main insanity of CORBA. Hiding that something is IPC
> > results in you thinking things are working one way when in fact
> > they're working completely differently and subject to a load of
> > unexpected failure modes.
> >
> > Other things to consider here is that hiding IPC can also result in
> > hugely inefficient IPC because you end up designing a pretty API
> > rather than efficient IPC.
> >
> > I could rant at length here about the various benefits of CORBA vs
> > message bus. But suffice to say hiding that there's a message bus
> > means you end up with CORBA again and all the attendant problems.
>
> I very very much agree. And I had to fight these CORBA problems for
> many years maintaining a bonobo based application. Please learn from
> history and don't fuck up our platform again.
>
> This should be required reading for everyone that ever touches IPC:
> http://research.sun.com/techrep/1994/abstract-29.html

Ok, I'm convinced.  Sorry for the noise.  (That's an excellent read:
short and clear, but still very thorough.)

However, I'm still not convinced that the IDL for this should be some
weird C-like syntax that makes everything look like messages rather
than method calls.  In fact, that paper you reference even notes that
interfaces can still be defined using a 'normal' IDL, and then the
parser would generate implementation based on whether or not the access
model is intended to be local or remote, tailored for that access model.

And if we still absolutely must use a weird message-like syntax, then
why use a C-like syntax at all?  Seems like it would be less confusing
just to invent something new, or reuse something that already exists as
to describe message-passing interfaces.

        -brian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mikkel Kamstrup Erlandsen-2
In reply to this post by Havoc Pennington-3
2009/3/2 Havoc Pennington <[hidden email]>
Anyway, I think there is no difference between method calls and
message passing. The only difference is in whether the client side API
is made to look just like a native object. But that's totally
orthogonal to the IDL and to the wire protocol.

To quote yourself: "This is perhaps a misunderstanding". Or at least a provocative statement :-)

For instance Steve Vinoski (one of the RPC/distributed systems grand old men) has a lot of blog posts devoted to the subject of RPC vs message passing. A good starting point is PDF paper linked here: http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/

I think you can put an RPC style API on top of an IDL based on message passing, but putting a message passing API on top of an RPC style IDL might not be a good idea (depending on the IDL in question of course as well as the nature of the actual remote transport mechanism).

--
Cheers,
Mikkel

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: DBus IDL (Was Re: GLib plans for the next cycle)

Mark Doffman
In reply to this post by Brian J. Tarricone
Hi Brian,

>> I understand that there is no difference on-the-wire between a
>> function-call and message passing. The difference is in peoples
>> perceptions and expectations.
>>
>> When I read CORBA IDL and see:
>>
>> int AFunction (int, int);
>>
>> Because of the connotations provided to me by years of procedural
>> languages I expect this function call to be synchronous. I hope to break
>> these perceptions by providing a message-based IDL.
>
> I don't have this perception; I think you're mistaking your own
> perceptions for the majority's.
>
> One of the huge benefits of this entire exercise is to "hide" dbus calls
> and make them look like methods on an object.  If you're going to avoid
> calling dbus methods "methods," then I fail to see the point.
>
> Whether or not the object is local (in-process) or not is irrelevant.
> Whether or not the method call is sync or async is also irrelevant. It's
> a method call, pure and simple.  DBus itself even calls them method
> calls.  All you're doing by avoiding that in the IDL is making us learn
> and remember yet another confusing and incompatible syntax.
>
> I ask you to *please* reconsider not using some normal method-call
> syntax for the IDL.  There's really no reason to do otherwise.  If there
> really is a perception problem, people need to fix that on their own.
>

I am actually re-using something that already exists. The struct-like
syntax for message-passing interfaces is almost exactly the same as
google protocol buffers language.

http://code.google.com/apis/protocolbuffers/docs/proto.html#simple

Thanks

Mark
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-2
In reply to this post by Mikkel Kamstrup Erlandsen-2
Hi,

On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
<[hidden email]> wrote:

> 2009/3/2 Havoc Pennington <[hidden email]>
>>
>> Anyway, I think there is no difference between method calls and
>> message passing. The only difference is in whether the client side API
>> is made to look just like a native object. But that's totally
>> orthogonal to the IDL and to the wire protocol.
>
> To quote yourself: "This is perhaps a misunderstanding". Or at least a
> provocative statement :-)
>
> For instance Steve Vinoski (one of the RPC/distributed systems grand old
> men) has a lot of blog posts devoted to the subject of RPC vs message
> passing. A good starting point is PDF paper linked here:
> http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/
>
> I think you can put an RPC style API on top of an IDL based on message
> passing, but putting a message passing API on top of an RPC style IDL might
> not be a good idea (depending on the IDL in question of course as well as
> the nature of the actual remote transport mechanism).
>

I agree with what Vinoski says there, but he's pretty much talking
about the API, not what's on the wire.

There's only so much you can put on the wire; i.e. some kind of
messages ... given that it's a TCP socket, all you can change really
is what format they're in.  I can send a dbus message and get back a
dbus reply message, or send an http request and get back http reply.
I'm sending some parameters to the remote, it does something, it sends
back any results.

Anyway dbus has messages on the wire but I think that's quite happy to
be mapped to an rpc-looking (method call) sort of API, or not, as
people see fit. Personally my favorite mapping is in JavaScript and
looks like a method call except the method takes a callback arg which
receives the return values, rather than ever returning anything
immediately. Just as people might often do http.

No doubt this is just terminology confusion. The point is, you can
make dbus look like rpc or not. There's nothing in the protocol to
stop you going either way.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mikkel Kamstrup Erlandsen-2
2009/3/3 Havoc Pennington <[hidden email]>
Hi,

On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
<[hidden email]> wrote:
> 2009/3/2 Havoc Pennington <[hidden email]>
>>
>> Anyway, I think there is no difference between method calls and
>> message passing. The only difference is in whether the client side API
>> is made to look just like a native object. But that's totally
>> orthogonal to the IDL and to the wire protocol.
>
> To quote yourself: "This is perhaps a misunderstanding". Or at least a
> provocative statement :-)
>
> For instance Steve Vinoski (one of the RPC/distributed systems grand old
> men) has a lot of blog posts devoted to the subject of RPC vs message
> passing. A good starting point is PDF paper linked here:
> http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/
>
> I think you can put an RPC style API on top of an IDL based on message
> passing, but putting a message passing API on top of an RPC style IDL might
> not be a good idea (depending on the IDL in question of course as well as
> the nature of the actual remote transport mechanism).
>

I agree with what Vinoski says there, but he's pretty much talking
about the API, not what's on the wire.

There's only so much you can put on the wire; i.e. some kind of
messages ... given that it's a TCP socket, all you can change really
is what format they're in.  I can send a dbus message and get back a
dbus reply message, or send an http request and get back http reply.
I'm sending some parameters to the remote, it does something, it sends
back any results.

Anyway dbus has messages on the wire but I think that's quite happy to
be mapped to an rpc-looking (method call) sort of API, or not, as
people see fit. Personally my favorite mapping is in JavaScript and
looks like a method call except the method takes a callback arg which
receives the return values, rather than ever returning anything
immediately. Just as people might often do http.

No doubt this is just terminology confusion. The point is, you can
make dbus look like rpc or not. There's nothing in the protocol to
stop you going either way.
 
Right. Reading through the posts (and linked articles) in all the spin-off threads I think we all agree more or less. It is mostly a matter on how one puts it.

Here's to a brighter future of sweet message passing! :-)

--
Cheers,
Mikkel

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Ryan Lortie
In reply to this post by Matthias Clasen-2
Hi

Matthias Clasen wrote:
> One thing that has been tossed around for a long time is that it would
> be really good to have DBus support on the Glib level.

Agree strongly, but I'm not sure of the timing.  A couple of people have
raised a few questions with me recently (in light of the noise I've been
making about GVariant and GBus) about how this could be happening yet.

A few of the concerns that were raised:

- How will compatibility between EggDBus and GBus be?
   I think this is not a very big concern, actually.  These two things
   are currently aimed in very different directions.  GBus is very
   low-level at the moment, mostly only implementing things that EggDBus
   currently uses libdbus-1 to do.

- Why is there EggDBusVariant instead of GVariant?  How will these map?
   See below.

- Do we want glib depending on libdbus?
   It is my understanding that the intention is that glib is at the
   bottom of the stack.  I felt like the reason that the GIO/gvfs split
   occured the way it did was in a large part because the gvfs client
   would not be able to use libdbus if it was in glib.

- What of the license issues?
   GLib is LGPL.  libdbus-1 is not.  The recent attempt to relicense
   libdbus-1 failed spectacularly due to copyright in a large chunk of it
   having been acquired by a bank (or something?) when CodeFactory AB
   folded.

- How does it fit with gobject-introspection?
   It seems like there could be a lot of advantage here in terms of
   easily exporting objects on the service side without need for large
   tables, if/elseif/elseif statements or code generation.

- Do we need code generation?
   Somewhat related to the last question, clearly: maybe we can avoid
   having generated code.  There is precedent for generated code in glib,
   certainly (enums, marshalers, etc.) but adding more is still a
   significant decision -- particularly when alternatives are available.
   This is a huge ideological debate, of course: I'm not going to suggest
   that this approach is wrong, but I guess my preference would lie on
   the other side, and it seems like this isn't something that has really
   been flamed on as much as maybe it should be.  Havoc tried to bring
   this topic up in another thread and as far as I can tell it didn't
   get a whole lot of play there.

> There is also some work by Ryan Lortie on a Glib-compatible Dbus api
> called gbus. It is lower-level than EggDbus, and might be suitable as a
> replacement for libdbus. While I have no clear idea yet how EggDbus and
> gbus will eventually relate, it is worth pointing out that EggDbus' use
> of libdbus is an implementation detail that is not exposed in the api,
> so it would be possible to replace it by something like gbus later on.

GBus is in a completely different problem space than EggDBus, so there's
not much toe-stepping going on here.  I'm not certain GBus is stable
enough that I'd feel comfortable encouraging its uptake during this
cycle.  In the meantime, that means that we'd have to deal with the
license and external dependency problems that come with using libdbus-1.
  It also means that we might be in trouble later if we find out that
the abstraction was a tiny bit leaky.

I do intend to propose GVariant for glib this cycle -- I'm going to be
creating a branch of the newly-converted glib git repository and merging
GVariant into it soon.  Assuming all goes well, EggDBus could be using
it at this point.  This would make future transition to GBus extremely
easy and would avoid converting between two different value types that
do essentially the same thing.

Once we release EggDBus with one variant type or the other appearing on
the public API, we're more or less stuck that way forever.


> - What do we do about collections ? EggDbus adds typesafe GObject
> wrappers around GHashTable and GArray. Other people have grandiose plans
> to force java/.net style collection interfaces into GObject.
>
>    My proposal: Dodge the issue by just adding the minimal necessities
> to GObject: a type for GArray (GHashTable already has one), and an api
> to associate element type information to arrays and hash tables.

I suspect that this will be insufficient.  In general, the GType system
isn't powerful enough to express DBus types properly.  This is what lead
to the creation of GVariant.

Even if we have support for querying the element type of an array, for
example, we can get into situations where we can still have type errors.
  Consider the case of an array of arrays of strings (which is a fairly
simple DBus type: "aas").

In this case, if you have a GArray, and query its type you will see the
answer is "G_TYPE_ARRAY".  This doesn't help you very much.  You have to
grab one of the inside arrays and query its type.  If the top array
happens to be the empty array then you're really in trouble because now
you have no way of determining the (complete) type of this empty array.

It's also not reasonable to (dynamically?) create a new GType for the
exact type of every distinct DBus signature you encounter.


Cheers
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
Hi,

On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie <[hidden email]> wrote:
> - How does it fit with gobject-introspection?
> - Do we need code generation?

I'm on the same page with you here, but I think the fix is to split
the object mapping from the other pieces (as outlined in my long
manifesto previously). Then go ahead and get the other pieces stable
and usable, and give the various object mapping ideas and codebases
some more time to settle.

> - What of the license issues?
>  GLib is LGPL.  libdbus-1 is not.  The recent attempt to relicense
>  libdbus-1 failed spectacularly due to copyright in a large chunk of it
>  having been acquired by a bank (or something?) when CodeFactory AB
>  folded.

Just for the record, my comment on this has always been that the
license issues were not earth-shattering to begin with, and the
relicensing was just throwing a bone to people who cared. Not sure
"large chunk" is super accurate, either. As a practical matter this
topic is highly overblown.

Nobody has yet explained (to my satisfaction anyway) how the libdbus
license has an issue the LGPL does not have. Perhaps we should get
Luis or SFLC on the case, but I'm not sure it's worth their time.

http://log.ometer.com/2007-07.html#17.2

3 points here.

1. AFL+GPL is the same as LGPL+GPL in the case people are complaining about.

LGPL is a dual-license - the part that's the LGPL itself, OR you can
choose GPL. The part that's the LGPL itself is not GPL-compatible -
it's a totally different license. That's why it gives you the choice
of GPL instead. libdbus is the same way, but it's choice of AFL (much
less restrictive than LGPL) or GPL.

Remember, when you link a GPL program to an LGPL library you are using
the library under GPL. Same if you link a GPL program to dbus.

The difference between dbus and an LGPL library arises only if your
program is *not* GPL.  You have to choose whether you want LGPL or GPL
when using GTK, and AFL or GPL when using libdbus. You can't say your
program is using both choices. You have to choose.

If a program is GPL+Exception, I don't think you can choose GPL for an
LGPL library. You have to use the LGPL terms. This means, however,
that your program must, in its exception, allow linking to the LGPL
library. It could also allow linking to an AFL library, if so. If your
exception doesn't allow this, then your program's GPL terms require
that the library be distributed under GPL... but if the library is
GPL, you can't have the exception. So GPL+exception is not compatible
with an LGPL library unless the exception includes LGPL libraries.


2. It's unclear that the AFL2.1 is GPL-incompatible.

GPLv2 is hard to understand on this topic, so it's hard to know. GPLv3
may be clearer. But as generally understood, if you distributed
libdbus under either GPL version, you'd be licensing your patents
under GPL. All AFL2.1 requires is that if you sue *with respect to
libdbus* claiming libdbus infringes your patents, you can't distribute
libdbus. But distributing libdbus under GPL requires you not to sue
with respect to libdbus. So in practice, there is no situation AFL
adds further restrictions over GPL. The GPL already prevents you from
suing for infringement claiming that libdbus infringes your patents,
*while distributing libdbus yourself*, because distributing libdbus
yourself necessarily licenses your patents.

There is no way, under either GPL or AFL, to distribute libdbus while
simultaneously suing users of libdbus saying libdbus infringes your
patents. The licenses agree on this. As does LGPL for that matter.

So the situation where 1) AFL keeps you from doing something and 2)
GPL allowed you to do that same thing, does not ever exist. As a
result, I don't think there's a "further restriction." To me "further
restriction" means "prevents something the GPL allowed me to do" and
the AFL does not do so. AFL is pretty much an MIT/X11 license and an
extremely liberal and toothless patent clause (compared to the GPL's
patent requirements).

3. There's no practical issue, even if there's a theoretical one
(which I don't think there is)

_Even_ if I'm wrong on the theory (IANAL), the case where it even
_matters_ is that some non-software company who owns the assets of a
small business (codefactory) that went bankrupt years ago, somehow
opens a musty old file, cross-references it with open source forums on
the Internet, realizes they could disrupt the distribution of
something called "Rhythmbox," goes to lots of legal time and expense
to do so... and then we either rewrite the Anders-written code in
libdbus, or add an exception to the GPL in Rhythmbox, or relicense
Rhythmbox to GPLv3, or some other solution, and we solve the problem.

There are many things to worry about in life, but this is not one of them.


btw, I believe we were going to add a notice to COPYING in libdbus to
the effect of "all new code is also MIT/X11, and most code is MIT/X11,
but a few bits are GPL/AFL" so that new contributions are MIT/X11 and
we don't have to redo the relicensing mass email if we ever solve the
codefactory code. It doesn't look like this has been done, however.

Havoc

From the LGPL, why it's OK to link a GPL app to an LGPL library:

  3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library.  To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License.  (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.)  Do not make any other change in
these notices.

  Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.

  This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

David Zeuthen
In reply to this post by Ryan Lortie
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:

> Hi
>
> Matthias Clasen wrote:
> > One thing that has been tossed around for a long time is that it would
> > be really good to have DBus support on the Glib level.
>
> Agree strongly, but I'm not sure of the timing.  A couple of people have
> raised a few questions with me recently (in light of the noise I've been
> making about GVariant and GBus) about how this could be happening yet.
>
> A few of the concerns that were raised:
>
> - How will compatibility between EggDBus and GBus be?
>    I think this is not a very big concern, actually.  These two things
>    are currently aimed in very different directions.  GBus is very
>    low-level at the moment, mostly only implementing things that EggDBus
>    currently uses libdbus-1 to do.

Right, the point of the EggDBus effort is really just to provide a
reasonable object mapping for C programmers using GObject, e.g. the
focus is really the C object binding. Yes, this involves code generation
(and way too much code at the moment but that is fixable) since we care
about things like type safety and other crap.

Anyway, so Havoc made a good point that we should also making things
easy for non-C language bindings on top of GLib so he wrote a big
laundry list of things that I largely agree with (that won't affect the
C object binding that EggDBus gives you) and I'm planning to implement.

Presumably if EggDBus is using GBus instead of libdbus-1 this would have
to come from GBus ;-)

Some relevant threads

http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00121.html
http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00123.html
http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00026.html
http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00030.html

So, yeah, from a 50,000 feet perspective you are right that it's not
important for the EggDBus C object binding whether libdbus-1 or gbus or
whatever is used. The important point, however, is that the non C object
binding stuff is reasonably efficient so it's usable by non-C object
mappings without having to copy a lot of values around and allocate
memory to free it again nano-seconds later.

License issues aside, I'm not exactly sure why we'd want to avoid using
libdbus-1. My view has always been that application programmers should
not even have to know that libdbus exist because they should be using a
language specific object mapping that hides libdbus-1... using either
generated code or varargs-ish functions depending on your taste and the
size and complexity of the D-Bus service you are providing and/or using.

> > - What do we do about collections ? EggDbus adds typesafe GObject
> > wrappers around GHashTable and GArray. Other people have grandiose plans
> > to force java/.net style collection interfaces into GObject.
> >
> >    My proposal: Dodge the issue by just adding the minimal necessities
> > to GObject: a type for GArray (GHashTable already has one), and an api
> > to associate element type information to arrays and hash tables.
>
> I suspect that this will be insufficient.  In general, the GType system
> isn't powerful enough to express DBus types properly.  This is what lead
> to the creation of GVariant.
>
> Even if we have support for querying the element type of an array, for
> example, we can get into situations where we can still have type errors.
>   Consider the case of an array of arrays of strings (which is a fairly
> simple DBus type: "aas").
>
> In this case, if you have a GArray, and query its type you will see the
> answer is "G_TYPE_ARRAY".  This doesn't help you very much.  You have to
> grab one of the inside arrays and query its type.  If the top array
> happens to be the empty array then you're really in trouble because now
> you have no way of determining the (complete) type of this empty array.

If you are not using a D-Bus variant this information is explicitly
available as part of the interface contract and it is also in the the
introspection data

http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo

as a D-Bus signature.

For d-feet D-Bus debugging / introspection style apps you can also get a
EggDBusInterfaceInfo struct by introspecting objects at run-time (again
as a D-Bus signature) using egg_dbus_object_proxy_introspect(). If you
are using a D-Bus variant the signature is available on EggDBusVariant.

The point is that you can always get to the D-Bus signature and from
that you can infer the complete type.

So, you are right that the G type system _alone_ isn't powerful enough
if we do it this way. E.g. you will need to augment the type with the
D-Bus signature and then you have all the information you need. I'm not
sure that's a big deal.

(Note that in for most real-life apps this is not a big deal. People
normally code their applications against a known interface contract
(e.g. they know the D-Bus API at coding time) so they know exactly what
a value will contain.)

> It's also not reasonable to (dynamically?) create a new GType for the
> exact type of every distinct DBus signature you encounter.

If we wanted this we could have something like this

 #define G_TYPE_PTR_ARRAY(element_type)
 #define G_PTR_ARRAY_GET_ELEMENT_TYPE(type)

to do this. Just like dbus-glib has done forever.

The set of distinct D-Bus signatures you encounter in a app where you
would need to do this (e.g. no need to do this for primitive types) is
most likely bounded to a couple of dozen types at the most (unless you
are some odd-ball corner case like a D-Bus version of gconf-editor) so I
don't think this is a big deal at all.

     David


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
In reply to this post by Ryan Lortie
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:

> - Do we want glib depending on libdbus?
>    It is my understanding that the intention is that glib is at the
>    bottom of the stack.  I felt like the reason that the GIO/gvfs split
>    occured the way it did was in a large part because the gvfs client
>    would not be able to use libdbus if it was in glib.

This is not really a correct description. The vfs part of GIO is a way
to access whatever kind of filesystem you have availible on your
operating system/desktop. Whereas gvfs is an implementation of virtual
filesystem mounts specifically designed for modern unix desktops.

It doesn't really make sense to have gvfs in glib, as its not what would
be used on all platforms. For instance, its not used on win32, and its
not used when using glib on a non-desktop unix desktop (without a
session, dbus, etc).

One could of course put only the clients side of gvfs inside glib,
similar to the way we have the client side of some win32 http vfs stuff
in glib. However, this would mean we had to immediately freeze the
cross-process protocols and update them in lock-step which would be a
gigantic pain in the ass.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Gustavo Noronha Silva-5
In reply to this post by Matthias Clasen-2
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> - What do we do about the added 16bit integer types that are supported
> by the DBus protocol, but don't have corresponding fundamental types in
> GObject ? EggDbus currently has fundamental types for them.

It just stroke me. What about int32? Should it be added for completeness
sake, or it is a non-issue?

--
Gustavo Noronha <[hidden email]>
GNOME contributor

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Will Thompson-5
In reply to this post by David Zeuthen
David Zeuthen wrote:

> On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
>> Even if we have support for querying the element type of an array, for
>> example, we can get into situations where we can still have type errors.
>>   Consider the case of an array of arrays of strings (which is a fairly
>> simple DBus type: "aas").
>>
>> In this case, if you have a GArray, and query its type you will see the
>> answer is "G_TYPE_ARRAY".  This doesn't help you very much.  You have to
>> grab one of the inside arrays and query its type.  If the top array
>> happens to be the empty array then you're really in trouble because now
>> you have no way of determining the (complete) type of this empty array.
>
> If you are not using a D-Bus variant this information is explicitly
> available as part of the interface contract and it is also in the the
> introspection data
>
> http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo
>
> as a D-Bus signature.
I don't think that relying on having correct introspection data to
marshall messages is a sound idea for a DBus binding. The C
representation of an 'a{uas}' where the values are all the empty list
should contain all the information you need to determine its D-Bus type.
It sounds like with EggDBus that's not possible without you discovering
the type by external means. If the C-side type system isn't powerful
enough to express the D-Bus-side types (which GType isn't), then the
C-side type system should be improved. Gluing the D-Bus type onto the
side doesn't sound like a clean way to do this to me.

Apparently, back when Telepathy was started, dbus-glib used to have a
similar problem with collections containing structs. It relied on
inspecting the contents of a GValueArray to determine the type of the
struct it represents, which obviously can't work for a(ss) since the
array might be empty. (Rob Taylor fixed this by adding a parameterized
struct type.) More recently, Rob McQueen had to fix dbus-glib to allow
complex types in maps. If the binding gets the type system right and
complete from the start, problems like this (and the current situation
where dbus-glib can't send 16-bit ints, causing interoperability
problems with bindings which expect them) won't arise later.

Talking about switching EggDBus to use GBus or GVariant in the future
seems like a non-starter; it would inevitably involve breaking the API.
So before putting a D-Bus binding into GLib, we should make sure it's
good enough to represent D-Bus cleanly, without needing the library user
to jump through hoops to make it work.

> The point is that you can always get to the D-Bus signature and from
> that you can infer the complete type.

dbus-python has shown that that's not true. When marshalling a dict (for
instance), it has to guess what the type is, and it sometimes guesses
wrongly, leading to hard-to-debug problems. It tries to quietly
introspect behind your back to work around this, and that too causes
problems.

> The set of distinct D-Bus signatures you encounter in a app where you
> would need to do this (e.g. no need to do this for primitive types) is
> most likely bounded to a couple of dozen types at the most (unless you
> are some odd-ball corner case like a D-Bus version of gconf-editor) so I
> don't think this is a big deal at all.

I think regarding types more complicated than 'as', 'b', 'i' etc. as
"odd-ball corner cases" is a mistake, particularly when talking about
one of the core components of the GNOME platform. The fact that D-Bus
has an expressive recursive type system is good, since it means you can
model interesting concepts without forcing them into an incorrect
representation. But for this to be useful, the binding has to support
complex types just as much, if not more, than simple ones, particularly
in a language like C.

Telepathy uses some pretty complex D-Bus types; an example that comes to
mind is 'a{ua(a{sv}as)}'. If working with this type in the standard GLib
D-Bus binding is no less painful than it currently is with dbus-glib,
then using a component of the GNOME stack with a standard GNOME binding
will be unnecessarily difficult. I really don't want to end up in a
situation where I have to use an external library instead of the one
inside GLib to make working with Telepathy less painful.

Regards,
--
Will


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (268 bytes) Download Attachment
1234