[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: DBus IDL (Was Re: GLib plans for the next cycle)
From:       Mark Doffman <mark.doffman () codethink ! co ! uk>
Date:       2009-03-03 11:08:16
Message-ID: 49AD0FA0.3040600 () codethink ! co ! uk
[Download RAW message or body]

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
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]