--nextPart2221437.agj84XEGPz
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 =C2=A0 with KTTS in KDE4 is improve the API so that operations are
> more intuitive for users while keeping the API simple for application
> developers. =C2=A0To 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=20
can connect to one service and the service will have some=20
connection-state as long as the client keeps the connection open.
The solution to have the application name is not the best solution; if=20
only because that means you can not have two applications of the same=20
name connect to the client.  Having two channel-windows open in=20
konversation would be easiest to do with 2 connections instead of=20
konversation doing some magic on multiplexing.

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


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

Hope this helps you in solving this issue.
=2D-=20
Thomas Zander

--nextPart2221437.agj84XEGPz
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEuYjzCojCW6H2z/QRAkcxAKDWiu6I8WGAPCFDv+k12uQMGtGiWwCaA+q6
AweXk7Znl8VtMGNm7mv+zaY=
=uuJh
-----END PGP SIGNATURE-----

--nextPart2221437.agj84XEGPz--