boyska/radiomanifest-spec
1
0
Fork 0
Code Issues 2 Pull requests Releases Wiki Activity

why it is like this

Browse source
This commit is contained in:
boyska 2022-02-13 20:47:39 +01:00
parent 90805b57a0
commit 54a7bf9d80
1 changed files with 43 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
spec.asciidoc
View file

@ -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 ``<channel>>`` 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 ``<channel>`` 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]