On 30/08/2020 16.40, Emmanuele Bassi wrote: > That's the literal *opposite* of the correct approach: you must always start > from a compliant code, otherwise you're just writing something that is not > useful to people writing and consuming the freedesktop platform. > > If a specification is unclear, or it's missing cases, then you need to fix > the > specification. The freedesktop.org <http://freedesktop.org> specs might not > be > strict standards, but the whole point of the fd.o effort is to have a shared > place where to collaborate; we have multiple implementations already of the > specifications, but what we're missing is a shared reference for people that > are > either not using platform libraries such as GLib or Qt; or for people who are > in > the process of writing new platform libraries. If you start ignoring stuff > because "it can be changed" at any later date, then you're simply not > collaborating, and you're just writing a bunch of code for yourself.
What I had on mind is that I am aware of the freedesktop specs and will try to be complaint with them. However if anything of what I produce end up not benig complaint in the end, it can be changed to be. What is important here are the interfaces. xdg-mime is the interface used by xdg-open, so as long as compatible interface is provided, xdg-open can be developed, at this very moment my xdg-mime uses python-magic, which as you stated, is not up to freedesktop's specs, so it needs to be changed, however, shared-mime-info or libmagic, does not matter for the xdg-open development, the (new) xdg-mime returns mime type, and then (new) xdg-open can do it's thing. > (...) If you start ignoring stuff > because "it can be changed" at any later date, then you're simply not > collaborating, and you're just writing a bunch of code for yourself. I am sorry to hear that you see my effort as simply not collaborating, and indeed I am writing a bunch of code for myself, because I am generally unhappy with state of xdg-utils, and at the same time I put an effort to make it in a way that it can overtake current xdg-utils, by eventually be complaint with all the specifications. At no point I've expressed that I will be intentionally ignoring any specification anyway... -- Piotr. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg