Request for the 1.0 release
thiago.macieira at trolltech.com
Sat Feb 25 04:22:32 PST 2006
Havoc Pennington wrote:
>On Fri, 2006-02-24 at 12:48 -0500, John (J5) Palmieri wrote:
>> The DCOP parity issue is about the only thing I can think of that
>> would change API/ABI at this point. There needs to be an assessment
>> by the Qt guys of what we need to put in the TODO. Other things like
>> moving gnome-VFS to D-Bus are blocking on this also.
>There were a variety of things in recent threads that probably didn't
>get captured as todo items; though several probably aren't 1.0 stoppers.
>I don't think it's all on the Qt guys to catalog those, since there were
>also items brought up by others.
>Stuff that I remember that sounded possibly 1.0-ish:
> - the new dispatch status and fixing that deadlock
> - some way to implement dcop-like controlled reentrancy?
> (I consider this "if someone starts prototyping it tomorrow,
> maybe we could get enough info to decide whether to do it, but
> otherwise not a blocker")
> - fix the spec/docs on the NoReply annotation so people know what
> the heck it is
> - introduce a way to list exception names in introspection
Adding a couple more that I consider 1.0-blockers:
- automatic daemon starting from apps
- Win32 & MacOS X official support
- method calls with empty interface names: do we want to keep this or not?
Talking on IRC it seemed to me that this is legacy stuff and that we don't
want to keep it. However, it's in the spec and the libdbus library allows
us to do it. The dbus server daemon, however, simply drops the message
with an assertion failure, causing my testcases to freeze.
And nice-to-have for 1.0, but that don't block it:
- standardise error names for property & method access:
* no such object
* no such interface on object
* no such method on object/interface
* no such property on object/interface
* parameters don't match for method call
* access denied for property access (reading a non-readable; writing a
* error setting property (invalid type?)
- decide on overloading methods by interface and by parameters
This last issue generated quite a heated discussion in the #dbus IRC
channel on Friday: the spec doesn't say anything about whether
overloading methods with different parameters is allowed or whether
overloading methods with different interfaces is.
From what I'm told, the current decision is that we cannot have two
methods in one interface having the same name but different parameters,
but we're allowed to have two methods with the same name in different
interfaces and possibly with different semantics.
Aside from that, the DCOP-vs-DBus issues won't start to come up until we
actually start porting KDE applications from DCOP to D-Bus. I'd expect
this to start within 1 month (hopefully), but the bulk of the
applications won't be ported soon. The old deadlock problem I've
currently solved by making any call to D-Bus allow reentrancy, which
means users must write code to cope with reentrancy any time they make a
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech AS - Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060225/80c8c736/attachment-0001.pgp
More information about the dbus