Re: shared mime info: URI scheme handlers for non browsers
On Monday 17 October 2011 23:06:24 Patryk Zawadzki wrote: On Mon, Oct 17, 2011 at 8:23 PM, Scrool scroo...@gmail.com wrote: I'd like to ask you for clarification of URI scheme handlers section in Shared MIME-info Database spec. Quote from last paragraph: Note that this virtual mime-type is not for listing URI schemes that an application can load files from. For example, a movie player would not list x-scheme-handler/http in its supported mime-types, but it would list x-scheme-handler/rtsp if it supported playing back from RTSP locations. a) Let's have a video player that uses HTTP to download a movie and its subsequent play. This player should not register x-scheme-handler/http, right? b) Another video player that uses HTTP as a transport protocol for video streaming. This player may register x-scheme-handler/http? Claiming to handle x-scheme-handler/http is basically saying I can handle anything that you throw my way as long as it's HTTP. That includes regular web pages so I guess the answer is that no media-specific application should ever register for a generic protocol. Instead, the .desktop file should mention %u in the Exec line, so that the launchers know that this application supports HTTP urls. Ideally the .desktop file would also mention Protocols=http, but this proposal was rejected by the GIO people. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared mime info: URI scheme handlers for non browsers
On Mon, 2011-10-17 at 23:06 +0200, Patryk Zawadzki wrote: On Mon, Oct 17, 2011 at 8:23 PM, Scrool scroo...@gmail.com wrote: I'd like to ask you for clarification of URI scheme handlers section in Shared MIME-info Database spec. Quote from last paragraph: Note that this virtual mime-type is not for listing URI schemes that an application can load files from. For example, a movie player would not list x-scheme-handler/http in its supported mime-types, but it would list x-scheme-handler/rtsp if it supported playing back from RTSP locations. a) Let's have a video player that uses HTTP to download a movie and its subsequent play. This player should not register x-scheme-handler/http, right? b) Another video player that uses HTTP as a transport protocol for video streaming. This player may register x-scheme-handler/http? Claiming to handle x-scheme-handler/http is basically saying I can handle anything that you throw my way as long as it's HTTP. That includes regular web pages so I guess the answer is that no media-specific application should ever register for a generic protocol. Exactly. Other examples include media-only streaming schemes. The media player would probably claim to handle x-scheme-handler/rtsp because it handles all types of RTSP URLs. Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared mime info: URI scheme handlers for non browsers
On Tue, 18 Oct 2011 13:16:48 +0200, Pavol Babinčák pavol.babin...@gmail.com wrote: On Tue, Oct 18, 2011 at 11:12, David Faure fa...@kde.org wrote: Instead, the .desktop file should mention %u in the Exec line, so that the launchers know that this application supports HTTP urls. %s doesn't itself mean it can handle HTTP URLs, does it? Reading Desktop Entry Specification (I think) means it accepts argument in URL format. This URL can be file or any other specified in x-scheme-handler/* (according to Shared MIME-info Database spec). Or am I missing something? Yes. That is a known ambiguity with %U. You don't know which URI schemes actually work. I guess, that's why KDE came up with X-KDE-Protocols. -- Rémi Denis-Courmont http://www.remlab.net/ ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
xattr preservation accross OSes
Hi, last month I presented a paper at the DC-2011 conference, describing the problem of incompatibilities in xattr implementations across OS and FS and their preservation when moving files across, and a possible solution. The paper is available here as PDF: http://dcevents.dublincore.org/index.php/IntConf/dc-2011/paper/view/53 The slides are here: http://revolf.free.fr/DCMI/2011/69-73-FR_DC2011_UXA.pdf And a small screencast I did showing the issue: http://revolf.free.fr/DCMI/2011/69-73-FR_DC2011_UXA_CurrentProblemDemo.ogv I'd like to start a discussion about how we could work together with other projects to achieve this, so please read and comment. François. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
