Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[Martijn Klingens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 April 2003 23:22, David Faure wrote:
> > The generic messaging framework that Neil and I want to set up for KDE
> > and which is currently discussed on the kde-pim and kaddressbook lists
> > will take the trader even further - it will ask for the user's preferred
> > implementation of, say, the messaging/irc protocol to contact dfaure and
> > then fire up ksirc, kopete, kvirc, bitchx or whatever app I've selected
> > for IRC that implements this new messaging API.
>
> That's still about loadable modules,

Eh, no, it's more abstract. It's about mapping the messaging type 
("messaging/irc") to the application associated with it (Kopete, ksirc, ...). 
This application is then launched (if not already running) with the proper 
arguments to contact the user that you selected from the address book.

All in all it has nothing to do with loadable modules.

> I think this solution would be very hard to explain to those who haven't
> followed this discussion. The concept is very internal ("to keep looking
> for services that also implement the parent servicetypes of the one we're
> looking for in the first place") - wow, how do you resume that in a single
> word, self-explanatory out of context?

"allowParentMatch" ?

> Waldo's IsAlso is a much simpler concept.

True - but it only covers mime types, making it far less generic and might 
even force us to add weird hacks to the messaging framework in the future to 
allow the same since the trader doesn't support it for non-mimetypes.

> Saying that "X-KDE-Derived might not be used depending
> on how the application makes its trader query" isn't really a clean
> concept, especially if we don't need it to solve the mimetype issue.
> IMHO the question is now whether there is really any need for
> a "no parent-servicetype-lookup" flag with components.

Not with components.

But there's more than just black and white, there's more than mimetypes and 
components as I hopefully made clear this time :)

> I don't agree. KRun should also activate the right viewer for a samba dir.
> Everything that uses the trader with mimetypes - but of course in the
> common case KRun acts as a wrapper.

Ugh - seems like I forgot an important one :/

> > Notice the resemblance to what I wrote above regarding the messaging
> > framework? :)
>
> Yes but since that mail I changed my mind ;)

You might have, but by doing so you turned the messaging framework's 
implementation into a potential problem...

> > I'm not too happy of that either - it also makes it impossible to use
> > e.g. ktradertest reliably. Better extend the language itself.
>
> (nothing would prevent a new cmd line argument in ktradertest)

bah :)

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

iD8DBQE+pbrEyU99+Wby2cYRAolDAKCaW8BtiW8tAOUn9iqjIYdjJ3oXywCdHZoS
Z7rlcIKilZvUgWO3++Fv3NA=
=k87h
-----END PGP SIGNATURE-----