zander at kde.org
Sun Jul 16 01:31:43 BST 2006
On Saturday 15 July 2006 20:27, Gary Cramblitt wrote:
> Use Case "Joseph"
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel