Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[David Faure]

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

On Tuesday 22 April 2003 22:52, Martijn Klingens wrote:
> You are here stating the implicit assumption that the trader is used either
> for components or mimetypes and nothing else. Part of the beauty of the
> trader in my opinion is however that it's much more generic than just that -
> the trader can encapsulate _any_ type of abstract interface in a query
> language.
> 
> In fact, in a way Kopete already uses this ability because neither generic
> Kopete plugins nor the more specialized protocol plugins are components in
> the sense that we usually use in KDE - they often have no GUI of their own
> apart from their configuration dialogs and some message boxes and don't use
> the KParts interface at all.

They are plugins, hence they are code, hence they are components ;)
If you consider that component is the most generic term for loadable modules,
(not only KParts) then this does fit into the definition.

KTrader is about finding a KService - which is a component (loadable module or app).

> 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, so IMHO inheritance still means the
same thing: if you're KopeteProtocolPlugin inherits the more generic
KopetePlugin, then when you're querying the trader for a KopeteProtocolPlugin,
you want such a thing in return, you don't want another kind of plugin (say a 
GUIPlugin or whatever else).

> > I see your point, but isn't that the most difficult solution to implement?
> 
> Hmm, I'm not sure if it's so hard to add an extra if() in the trader that
> enables the parent traversal or disables it and an extra keyword to activate
> it, but I don't know the actual trader code so I'm not qualified to judge.

I was talking about the need to actually fix the apps....

> Given the above (and the other uses that I see for the trader) I think it's
> the only viable solution though. The alternatives would render the trader
> less functional for abstract interfaces, and thus less attractive for many
> potential uses.

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?
Waldo's IsAlso is a much simpler concept.

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.

> > each and every app would need to be fixed.
> 
> Assuming we default to KDE 3.1's behaviour (don't traverse) we only need to
> fix Konqueror as far as I can see it to support Coolo's new Samba code.

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.

> All ReadOnly/ReadWrite/KOffice parts simply continue to provide what they do
> now - their part, and only the code that _calls_ the traders needs to be
> updated. Besides Konqueror I don't know a trader client in KDE CVS that
> currently can make use of parent traversal.

Lots of apps launch other apps :)

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

> I'm not sure how KIO uses the trader, but if it's in a single centralized
> entry point it might be better to add the "enable traversal" flag in KIO's
> query and keep the trader itself generic.
KTrader is actually a wrapper around KServiceTypeProfile, to take into
account the user's preferences. The actual ksycoca query is then delegated
to KServiceType::offers(). Interesting: this one, in turn, has code to
"also look in all/all and all/allfiles". This could be generalized with "look
in all the X-KDE-IsAlso entries, as well as in all/all and all/allfiles if not a dir",
if implementing Waldo's solution.

> > The other solution would be a new overload of KTrader::query() with an
> > enum (Auto,AcceptParentServiceType,RejectParentServiceType) - but I'm
> > reminded of Torben's reason for the whole trader language: so that there
> > is no need for an API change for every new query feature :)
> 
> 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) 

- -- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+pbKO72KcVAmwbhARAsAAAKCpAqvKHP8fGKDpwr7T0fSlsAjOBQCfWa3I
7cDsJqbkCt0P63DbquE/i0I=
=yzLq
-----END PGP SIGNATURE-----