[Xesam] Wrapping up for Xesam Search Spec RC3

[Michael Albinus]

"Mikkel Kamstrup Erlandsen" <mikkel.kamstrup at gmail.com> writes:

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

That's true, but who knows ... I can also imagine running Xesam
without any desktop, just plain ASCII screen (you know my Emacs
background :-)

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

Evolution is desktop neutral. But what if there are different desktop
specific applications, which are able to handle a hit? Like a zip
browser, which could exist as "kzip" and "gnomezip" (just hypothetical
names, don't beat me!).

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

As I said: it is just the workaround I've applied using Ontology95.
I'm not against dedicated fields.

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

I'll see. It is a little bit complicate, because Emacs 23 is now in
feature freeze; most of my implementation exist local only these days.
It might still need some weeks, until new commitments towards the
Emacs trunk are possible.

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

According to RFC 2045, that won't be necessary:

"The process of defining new media subtypes, then, is not intended to
 be a mechanism for imposing restrictions, but simply a mechanism for
 publicizing their definition and usage.  There are, therefore, two
 acceptable mechanisms for defining new media subtypes:

  (1)   Private values (starting with "X-") may be defined
        bilaterally between two cooperating agents without
        outside registration or standardization. Such values
        cannot be registered or standardized. ..."

That's why I have taken "application/x-debbugs".

Best regards, Michael.