Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[David Faure]

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

On Tuesday 22 April 2003 21:31, Martijn Klingens wrote:
> 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 :)

It is - or rather it was giving the same result as this, before I changed
KService::hasServiceType :)

> I thought all this was already in place, which is why I didn't understand the
> problem...
The servicetype inheritance was in place - but not the mimetype inheritance
support (with the other semantic).

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

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

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

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

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

Yes, just like: when I'm looking for a text _editor_ component, I don't want to end
up with a simple text viewer.... Imagine what you'd say if KMail or KDevelop ended
up embedding a _readonly_ text viewer where there is currently an editor :)

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

I see your point, but isn't that the most difficult solution to implement? Instead
of fixing the libkio code to do the right thing, each and every app would need to
be fixed. 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 ;)
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. 
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 :)

- -- 
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+paT872KcVAmwbhARAnD+AJ9zmusxHXlSIxQF8Xnbn6dUDn5UtwCeJYbe
L/fcO2LPqtwqbF0TLgCUwPs=
=Ip1j
-----END PGP SIGNATURE-----