[Xesam] Wrapping up for Xesam Search Spec RC3

[Mikkel Kamstrup Erlandsen]

2008/9/4 Michael Albinus <michael.albinus at gmx.de>:
> "Mikkel Kamstrup Erlandsen" <mikkel.kamstrup at gmail.com> writes:
>
> Hi,
>
>> Unless people cry fowl the changes described on
>> http://xesam.org/main/XesamUpdates will be final.
>
> I don't want to be the grinch, but I still have a comment on the point
> "Details of xesam:url".

Don't hold back. I post with the purpose to get comments after all :-)

> You propose to introduce a new field
> xesam:urlVendor. The contents of this field is linked to applications,
> via a .desktop file.
>
> I believe, this is too restrictive, because it would prevent Xesam to
> run in environments, where applications are not identified via
> .desktop files. Imagine other operating systems ...

My personal opinion is that we mainly target the freedesktop.org
operating systems, but this has never really been discussed...

> And there is also the problem, that there might be different
> applications, which could be able to handle the URL in question, for
> example an KDE application, and a Gnome application. Which application
> shall be chosen by the search engine then?

In cases where multiple programs can open the url it is likely that no
urlVendor should be set. The idea was to only set it for
vendor-specific urls. Ie for pointers into Evolutions email cache etc.

> I believe, the hint, given in xesam:urlVendor, shall be more
> neutral. It shall be more a hint, in which context the search engine
> has retrieved the URL, and not which client is recommended for best
> view.

That was also the idea.

> In my current implementation of a Debian BTS search engine, I use such
> an approach. xesam.url returns always a valid (http) URL, which can be
> browsed. In xesam:mimeType I return the value "application/x-debbugs",
> which says, that the URL is a reference to a bug report.

And "application/x-debbugs" is a sub-mimetype of html or xml i take
it... Mimetype matching for application selection will probably
suffice in most cases, but will begin to fall short in the more tricky
cases, like the email example above.

> In my Xesam client, there is a plugin mechanism for arbitrary
> applications. If an application registers there for all hits, which
> have a given value in xesam:mimeType, that application gains control
> whenever such a hit shall be visualized. If there is no registered
> application, the default viewer (browser for the URL) is applied.

Speaking of which, if you are up to it you could note your app on
http://xesam.org/main/XesamUsers

Sounds like the right approach. The idea of urlVendor was not to
interfere with these set ups, but to help in the exotic cases

> By this approach, the search engine does not need to know, which
> client will do the visualization. Of course, I don't insist to use
> xesam:mimeType for this information return; it could be
> xesam:urlVendor as well.

Maybe urlVendor could be replaced by creative mimeType usage, but I am
not entirely sure. It would require registration of a lot of exotic
mimeTypes in the mime db for it to work properly.

If I read you right you are not entirely against it, and we might even
agree to some point. It was not my intention to let urlVendor be the
primary method to look up the proper application, but to tender to the
more tricky cases. Another example would be a .png inside a .pdf
inside a .zip. The search engine MyIndexer might assign an url like
file:///home/mikkel/myArchive.zip#myDocument.pdf#myImage.png. The
mimeType of the object would be image/png or what ever the right name
is. Hopefully MyIndexer had some app in mind when constructing the
url, so that I can open it with, say, MyLeetApp.

-- 
Cheers,
Mikkel