Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[Martijn Klingens]

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

On Tuesday 22 April 2003 22:24, David Faure wrote:
> Konq wants to offer all possibilities, in its RMB popup and in the Document
> menu. But that's not my point. Of course you want the most preferred - the
> question is whether you compare A's handlers with B's handlers, or if you
> only look at B's handlers first (and choose amongst those only).

Whichever is most compatible to KDE 3.1 I'd say - if possible 100% compatible, 
or there would be major problems in apps coded against 3.1 (or 3.0) and 
running against newer kdelibs. We can't do that until KDE 4.

> When searching for components, if I'm looking for a B specifically, then it
> means I don't want something as basic as an A.... otherwise I would be
> looking for an A in the first place, wouldn't I? :)
> (e.g. B=KoDocument and A=ReadOnlyPart...)

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.

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.

Here we're truly speaking of abstract interfaces that have nothing to do with 
either mime types or components (though the messaging framework is somewhat 
related to mimetypes and probably needs similar behaviour - i.e. traversing 
parents, and the kopete plugins are more similar to components).

> 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.

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.

> 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.

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. KOffice and Kopete certainly 
can't. Maybe KDevelop can make use of it.

> This is of course the only solution if we need the
> flexibility, but at the moment I can't see any case where
> - a mimetype query would need the "no parent mimetype lookup"
> - a servicetype query would need the "parent servicetype lookup"
> Hmm, at least for components. Maybe some people use servicetypes for
> something like document types (i.e. analog to mimetypes). Servicetypes are
> so generic, they can be used one way or the other ;)

Bingo :)

Notice the resemblance to what I wrote above regarding the messaging 
framework? :)

> I guess this means: servicetype queries would indeed benefit from this
> flexibility, but really, all mimetype queries should just go ahead and
> accept parent mimetypes. So if we add a trader syntax extension, the
> default to use when that extension is not specified would depend on whether
> the query is about a servicetype or a mimetype.

That would add a special case for mime types in the trader though.

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.

> 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.

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

iD8DBQE+pausyU99+Wby2cYRArqYAJ9SeEGdC9YPhNa771aExkya62dE7wCgot4I
rPVL2gGr+m72xJmiHtZ7jNU=
=UWtS
-----END PGP SIGNATURE-----