Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[David Faure]

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

On Tuesday 22 April 2003 20:19, Martijn Klingens wrote:
> On Tuesday 22 April 2003 19:31, David Faure wrote:
> > Say you have a type of service A (e.g. KParts/ReadOnlyPart)
> > and a more specialized type of service B (e.g. KParts/ReadWritePart).
> > B inherits from A, which is the usual notion of specialization.
> 
> Yup, this is also how Kopete does it (Kopete/Protocol inherits Kopete/Plugin), 
> and I did it like this after your explanation at FOSDEM ;-)

Servicetypes again, so indeed it fits the same concept ;)

> > Here's the new reasoning (after my discussion with coolo, and this is
> > what led to the recent change in CVS):
> > => No, it doesn't necessarily support a "more generic" type of service,
> > it can only do the more specialized one.
> 
> Hmm, to me that sounds like "the service doesn't inherit the base class" and 
> the X-KDE-Derived line shouldn't be in the service type's .desktop file...

Interesting thinking.

> > And when asking the opposite question: "if a service T says it
> > implements A, does it implement B as well?", the answers are opposite
> > ("certainly not" we would say for a ReadWritePart,
> > but "yes" if we consider that B is only a special case of A).
> >
> > In coolo's case, a "samba workgroup" is a special kind of directory.
> > So when the iconview says it can display directories, it means it can
> > also display more specific directories, such as the samba workgroups.
> 
> But why does this need changed inheritance semantics?
> 
> 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).

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

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

* the distinction remains. We only need this "parent servicetype lookup" for
mimetypes, not for servicetypes. 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".
More generally, if we're asking for a given servicetype, it means we expect
certain capabilities, which a "handler for the parent servicetype" will not
provide us with.
So we end up with again "if mimetype then foo" code - IMHO it makes
little difference whether that code is in KTrader/KUserProfile or in
KService::hasServiceType...

- -- 
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+pZPi72KcVAmwbhARAqRUAJ9NK2HbnV5nyVpuhm3CCRQjgTemdwCeMnae
bZDhvPFWm2pIWPwxv5UT/pc=
=+23x
-----END PGP SIGNATURE-----