Request for the 1.0 release

[Thiago Macieira]

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 
read-only, etc.)
  * 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 
D-Bus call.

-- 
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
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060225/80c8c736/attachment-0001.pgp