Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[Martijn Klingens]

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

On Tuesday 22 April 2003 21:11, David Faure wrote:
> > I mean, if you have the KDE mime types Dir and Samba (Samba inheriting
> > Dir) and the KPart KFileIV that implements the mime type Dir, then if you
> > actually get a Samba mime type, shouldn't the trader try to find a
> > handler for Samba's base class (Dir) if there's no handler for the Samba
> > type?
>
> Ah, I see. So when T implements A, "does T implement B?" would still say
> no, but then the trader would look for services that implement A....
> ... and then it would find T. So what difference does that make?
> I think this is another way of ending up with the same result.... except if
> we can make this "lookup for parent servicetypes" only happen when needed,
> in which case it would indeed be a good solution (see below).

I'm actually surprised it isn't already working like this :)

> > Maybe I'm missing something here, but the more I think about this the
> > more I fail to see why this is needed in the first place :(
>
> Which "this"? The mimetype inheritance? Well at the moment we don't have
> this "trader lookup for each parent servicetype".

Apparently :)

I thought all this was already in place, which is why I didn't understand the 
problem...

> The problems I see:
> * do we compare the preference of all "parent servicetypes", or do we only
> look up parent servicetypes if there is 0 offer for the current
> servicetype? If I don't like B's specific handler, I can make it less
> preferred than the generic handler for A (well, I could also remove the
> association altogether in the 2nd case...)

Suppose a handler for HTML files. KHTML can handle them, but the Kate part can 
handle them too, as can KOffice and Quanta.

Usually you want the closest match that you selected for the trader. In fact, 
I can't think of a case where you _don't_ want the handler that is specified 
in keditfiletype (or another selector in the case of non-mimetypes).

> * the distinction remains. We only need this "parent servicetype lookup"
> for mimetypes, not for servicetypes.

Don't we? I think for normal service types it makes sense as well. After all a 
service type is just a generic abstract interface and it's perfectly possible 
to come up with an abstract interface that is not a mime type but does 
benefit from the general idea that a more generic class would do too.

> Otherwise when looking for a KoDocument part we'd fallback to any
> "ReadWritePart" - e.g. we would end up with kate when looking for "a
> KoDocument that can import text/plain".

What do you mean with "when looking for a KoDocument part" ? If you mean the 
case of KOffice where you don't want to end up with a generic base class I 
think you need to extend the trader syntax to not traverse the tree upwards 
for other matches, even if there is a match that would be "more preferred" 
from e.g. konqueror according to keditfiletype.

Alternatively the trader syntax can be extended to actually _enable_ parent 
traversal when looking for handlers and have it off by default. That would 
more closely match the KDE 3.0.x and 3.1.x behaviour and avoid most 
compatibility problems.

Either way, it's the _CLIENT_ application (konqueror, koffice, kopete, kate, 
...) that ultimately decides whether traversal is wanted or not and not the 
service type or kdelibs.

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

iD8DBQE+pZikyU99+Wby2cYRAiPsAJwKWVhcq3PTzzoL/Rkw/l89cMQG8gCeJn1p
54Xxu6LmWkN32SCG1WfCAWM=
=ppPh
-----END PGP SIGNATURE-----