"Mikkel Kamstrup Erlandsen" <[EMAIL PROTECTED]> 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. _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
