DBus/QtDBus Concerns

[Thomas Zander]

On Saturday 15 July 2006 20:27, Gary Cramblitt wrote:
> Use Case "Joseph"
[snip]
> I agree with both of these assessments, so one of the things I'm trying
> to do   with KTTS in KDE4 is improve the API so that operations are
> more intuitive for users while keeping the API simple for application
> developers.  To accomplish this, KTTSD must know from which
> applications the service requests are coming.

This usecase refers to the idea of having a connection. Several clients 
can connect to one service and the service will have some 
connection-state as long as the client keeps the connection open.
The solution to have the application name is not the best solution; if 
only because that means you can not have two applications of the same 
name connect to the client.  Having two channel-windows open in 
konversation would be easiest to do with 2 connections instead of 
konversation doing some magic on multiplexing.

There is a suggestion to make (virtual) connections be native to dbus, and 
until that happens you can simulate this in a small layer on top of dbus 
as well.  For example, in a framework I wrote (pvr.net) I sent a unique 
random ID in the connecting packat from the client to the service. This 
will make the service create a Map with properties unique for that 
connection. I will keep using that same ID for that client until there is 
a connection problem and things timeout. Each time a packat comes in the 
corresponding Map object is fetched and passed to the layers above. 
Giving the impression of a real statefull connection.  Ok, this is a very 
very quick overview of how this can be solved better without knowing the 
client application name by introducing a layer on top of a 
connection-less protocol.  Much the same way that TCP/IP does on top of, 
for example, ethernet.


Use case Mary can be solved in much the same way; there is statefull 
connection that requested the special 'status' of system manager and only 
via that connection can a global pause be executed. This is implemented 
using a handshake (meaning; request status and await OK) allowing the 
service to deny a system manager request based on policy like allowing 
only one at a time.

Hope this helps you in solving this issue.
-- 
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/20060716/b27bf922/attachment.sig>