KNotificationAreaItem

[Thiago Macieira]

Olivier Goffart wrote:
>Le Tirsdag 21 april 2009, Thiago Macieira a écrit :
>> Olivier Goffart wrote:
>> >Doesnn't the fact that this service is required show a flaw in dbus
>> > itself. Is there a way to ask dbus all the running client that
>> > provides a given interface?
>>
>> No. The running service is the correct thing to do.
>>
>> Interfaces are not registered with D-Bus. To register, there has to be
>> a call for that and something has to keep a list. That's what the
>> deamon does.
>
>Sure,
>But i'm telling dbus-deamon should be that deamon.

The dbus-daemon's job is just to pass messages around.

>Let's say i want to query all the running media player so i can list
> them to eventually play something :  we have to create a special deamon
> ?

See the MPRIS case: put the information in the front, in the service name. 
The service names is something that the daemon does know, so it's easy to 
find.

> Let's say i want to list all the IM client to know the status of a
> contact : we need a special deamon.

Yes, that's correct.

>Let's say i want to list all the "kpart" application to know which
> documents are open : we need another deamon ?

Yes.

>This was very possible with dcop.

No, it wasn't. The DCOP server did not keep the list of objects. You have 
to query the application to find that out what those objects were and what 
they implemented.

What it did was that it supported a "find" type of message, which was 
delivered to all applications in sequence. In turn, the applications 
delivered to all objects and stopped at the first that worked.

That works as long as there's only one. If there's another, you get a non-
deterministic condition, since the order could change from run to run.

If you have only one, you've reached all. And if you're describing a 
message that reaches all targets interested in it without knowing what the 
targets are, you're describing a signal. The difference is that DCOP did it 
by a push method (i.e., the message was shoved down the throat of 
applications), whereas D-Bus uses an opt-in method (the application has to 
express interest).

The only thing that D-Bus signals don't do (which DCOP find messages did) 
is to tell you back what matched.

>What i want is  "gives me a list of running services that implement a
> given interface"

And you'll never get that. You actually want "give me a list of these 
services". 

Interface is just the set of functions available. And if you decide to 
change it completely, you have to write a new interface. 

You have to think in terms of services actually.

What are the IM clients running? List the org.freedesktop.im-* services. 
You want KParts? List the org.kde.KPartServer-*.

Again: this is opt-in. This has to be designed into the applications from 
the start. Not bolted on after-the-fact.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090421/52e408cd/attachment.sig>