DBus/QtDBus Concerns

[Thomas Zander]

On Wednesday 12 July 2006 04:33, Gary Cramblitt wrote:
> 3.  Connections.  I don't understand the need for DBus to define
> connections. 

Isn't that the same as ethernet having connections while it all packet 
switched?  There is no need per see, but it makes some things a lot 
easier.  Having connections scales better.
I have very little knowledge of dbus, but I can imagine connections 
leading to an optimization where messages are sent to the other client 
instead of broadcasted making things like streaming data possible.

> QtDBus
> -----------
>
> 1.  Documentation.  The documentation for QtDBus is presently barely
> adequate with numerous typos and errors. 

The good thing is that its maintained by Qt; so any suggestions/patches 
can be sent to qt-bugs AT trolltech.com.  Ask youself; what are the 
chances that Qt (which has a standard to uphold) will ship final docs in 
the state you describe? I don't think you'll have to worry much.

> 2.  Sender Names.  If you need to know a message's sender, this is
> presently rather painful, requiring hand-coding of adaptors.  Knowing
> who you are talking to is fundamental.

Actually; I implemented various similar frameworks; including one 
grid-computing solution, and I never ever had the need to find the name 
of the service connecting to me.
This is only needed when encrypting a connection and that implies a 
handshake which will do something like this anyway.


Many of your other points are attention points that should be looked at.
I fully understand your hesitation, naturally, but in my opinion having 
people use an unfinished framework that is at a state where it will not 
bring regressions (except speed) is a normal part of replacing one 
technology with another while incorporating the feedback of all its 
users.

In fact; your excellent mail proves to me that this is the correct road to 
take, make everyone use dbus so people will not wait until the last day 
to 'switch' and then start to complain when its too late :-)  Only next 
time some 'roadmap' would have been nice, yeah.

> Finally, all of the above are *concerns*.  I am *not* saying that the
> move to DBus *is* a mistake; just that it *might* be a mistake,
> possibly a costly one.

This is software, and the fundamental design is still fluid. As long as we 
have the ability to influence the design of dbus (and we do have that, 
last I heard) then its never a mistake as we can fix the problems.
Please keep in perspective the gains we have by using a system that not 
only kde but all the parts of a computer use.
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060712/87bcb1e7/attachment.sig>