From 54a7bf9d8032864711ce76e066f7006dff6abd55 Mon Sep 17 00:00:00 2001 From: boyska Date: Sun, 13 Feb 2022 20:47:39 +0100 Subject: [PATCH] why it is like this --- spec.asciidoc | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/spec.asciidoc b/spec.asciidoc index 2508d96..5e4f29c 100644 --- a/spec.asciidoc +++ b/spec.asciidoc @@ -210,6 +210,49 @@ https://www.radio-browser.info/ fornisce molte info utili su delle radio. Grazie RadioDroid is a fine Android app to listen to stream. We'd like to have an improved version of RadioDroid that also includes features that RadioManifest provide. See the _Player_ use case. +== Why it is like this + +Of course, similar goals to the one achieved by RadioManifest could have been achieved in different ways. So +let me try to answer to some frequently answered question. More in general, we tried to adhere to +link:http://scripting.com/2017/05/09/rulesForStandardsmakers.html[Rules for Standards makers] + +=== Why XML? Why not JSON? + +I understand why XML is fading out. Believe me, this choice is not about the technical merit of XML in itself! + +Feeds are still very important. While JsonFeed may look promising for the future, RSS is the present. +Since any reasonable RadioManifest client would also need to implement feed parsing, they need a XML parser +anyway. So, let's stick with this. + +=== Why are ``shows`` based on XBEL, instead of OPML? + +Good question. OPML are heavily used in the RSS-world, so it would have made sense to base our ``shows.xml`` +format on OPML. However, OPML looks not so easy to extend. XBEL is much easier on this front. We want our +format to be easy to extend in the future. + +=== Why not add some more field here and there? + +Good point. It's pretty hard to define a threshold: should we add a ``slogan`` for a radio? Image? Logo? +Gallery? Frequency of broadcasting? We applied the principle of sticking to (what we felt was) the bare +minimum, knowing that the standard is easily extendable, so future needs can be accomodated. + +=== Why not extend RSS itself? We could add more info to the ``>`` tag + +That's a nice idea. However, we think this would make the adoption harder. + +Let's say that you are using a CMS for your radio right now. Let's say Drupal (but it could be anything else +of course). You should teach Drupal to put this nice information into the ```` section of its feeds. +How easy is it? I don't think this is *so* easy. + +With the current setup, the radiomanifest.xml can be used as a very simple static file. Most web servers can be +told to serve this from a directory on the server, without passing through your CMS code at all. +This static file is also changing very rarely: it's totally reasonable to write it once, and forget about it +for years, so you don't even need a special software to keep it working. + +Of course, nothing prevents a CMS to generate this file dynamically, making this way simpler for users. But we +wanted RadioManifest to be deployable as _"just a bunch of static files"_, as a way to increase early adoption. + + == Meta This specification is versioned on {url-repo}[Git]