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



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
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Thanks

Mark



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]