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

List:       kde-core-devel
Subject:    Re: DBus/QtDBus Concerns
From:       Thomas Zander <zander () kde ! org>
Date:       2006-07-16 0:31:43
Message-ID: 200607160231.47927.zander () kde ! org
[Download RAW message or body]


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

[Attachment #3 (application/pgp-signature)]

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