D5621: Install xdg mimetype definitions for OpenCL C & CUDA C

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In https://phabricator.kde.org/D5621#108263, @aaronpuchert wrote:
  
  > By the way, I posted the question to Khronos. Their preferred channel <https://www.khronos.org/about/technical-support/> seems to be opening an issue on one of their GitHub repositories. So I opened issue #27 <https://github.com/KhronosGroup/OpenCL-Registry/issues/27> at the OpenCL Registry <https://github.com/KhronosGroup/OpenCL-Registry>.
  
  
  Good!
  
  > However, I do not expect an answer. From Khronos' point of view OpenCL source code is just a string in memory. Compiling OpenCL directly from file is not possible. (As far as I know the API.)
  
  Mimetype is not just about files in the filesystem, but also in the clipboard, as attachments to messages, network-transferred blobs etc. Kind of type metadata for any byte streams/blobs :) Having that help here and there programs to do better guesses what to do with some blob submitted over a generic API (like clipboard), so it's worth pushing for some type
  
  > I'm not sure there will ever be a standard type. Not even for C there is: while `shared-mime-info` defines it as `text/x-csrc`, I get `text/x-c` when running `file -i` on a C source file.
  
  Yes, quite frustrating. Was'nt that the nice thing about standards that there are so many to pick from? ;) shared-mime-info tries to encounter that wildness with unregisterd mimetypes a little by here having that alternative also registered, via `<alias type="text/x-c"/>`, so some mapping is possible for code using shared-mime-info (which IIRC `file` yet has to do, they seem to maintain their own db/magic).
  ((And then mimetype (usage) is also not the best content type tagging system, e.g. does it have little/no help about format versions (just think about `application/msword`). But it's what we have right now.))

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D5621

To: kossebau, #kdevelop, qi437103, aaronpuchert, kfunk
Cc: nalvarez, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170509/39ae9aaf/attachment.html>