andybee / radiotag-doc Goto Github PK

Considering the benefits we've encountered from widening authentication to a x-media protocol, could we do the same with RadioTAG, to allow a single spec to adopt the previous work done with TV Tag.

If we took this initial step, it's easy to see it being extended further to encapsulate VOD too.

Could we abstract the radio-specific bits from the spec and develop a "tagging core" with appendix/additional docs that add the broadcast parameters in?

One possible way to resolve #7 and #8 and increase the scope of the project would be to abstract the current "station" parameter in favour of a URI.

A URI could then represent any one of a number of things:

• Broadcast parameters (as in the DAB EPG/RadioEPG specs, e.g. "dab:ce1.ce15.c224.0")
• A URL for AOD (e.g. "http://downloads.bbc.co.uk/podcasts/radio1/r1grimmy/r1grimmy_20140221-0157a.mp3")

It could even get very "abstract" as the URI could represent anything - a web page, a MBID, etc. The scope of accepted URIs would then be limited by the implementation (e.g. a radio class received only accepts broadcast and audio URLs in the realm of the broadcaster).

If we went down this route, time would become optional for items not in the time domain. We could incorporate time in the URI (e.g. "dab:ce1.ce15.c224.0#1312195118" or "dab:ce1.ce15.c224.0?t=1312195118") and vary it for different contexts (e.g. AOD is an offset not time "http://downloads.bbc.co.uk/podcasts/radio1/r1grimmy/r1grimmy_20140221-0157a.mp3#offset=116s")

The RadioDNS suite of applications are moving away from having "brands" (RadioTAG, RadioEPG) to having descriptive names to fit in more closely with ETSI specification-style titles. I'd like to propose retitling the specification in a similar fashion, such as "Simple interaction methodology for hybrid radio".

As an extension we could begin retiring "tagging" as a term as it has been a contentious issue throughout the project. This impacts things like the /tag endpoint; we could move to describing 'tags' as 'events' and so rebrand the endpoint /event (e.g. REST'fully
POST'ing an event to /event).

If I remember correctly, this was a late addition for Frontier Silicon to ease implementation. It feels a little excessive to me to include this in every response.

I also think the value of this header is now equally covered by responses from the SP under the CPA protocol.

BBC R&D have held several workshops around their Radio Dan project, inviting developers and members of the public to develop their "wrong radios". A recurring theme is the inclusion of at least two binary buttons; +/-, Like/Dislike, Vote Up/Vote Down.

This has inevitably brought a number of people back around to the question of why RadioTAG is just a single button interaction, particularly if people thinking outside the constraints of an existing draft specification all favour a couple of buttons to be able to infer emotion around their interaction - positively or negatively.

I've thought a lot about this issue and I still believe the unique quality of RadioTAG is the simplicity of single button interaction. During Digital Radio Week in Geneva there was a reasonable amount of discussion about in-car listening and in particular the impact of new functionality from hybrid devices. On several occasions concerns were raised over the suitability of interactive controls to be used whilst operating a vehicle. Tag in it's current state overcomes this issue with a single button push.

By having a single button it's easier to make the argument to car manufacturers to integrate tag in to a steering wheel "stalk" control providing a safe option for in-car interaction. Similarly, it's easier to get a manufacturer of a very low cost device to put a single button in over multiple buttons.

I worry that even by opening the specification to allow additional interaction types, purely for devices that are suitable and capable, we confuse the user proposition of how the application works and it will be confusing for users if it behaves differently on certain devices to others.

I'm keen to ease understanding through consistency. General trends for APIs are favouring JSON responses over XML and, whilst we adopt an existing standard in using Atom for the responses, it does feel a bit "heavy" for the relatively simple outputs from RadioTAG. An alternative:

GET /tags HTTP/1.1↵
Content-Length: ?↵
Content-Type: application/json↵
Host: radiotag.bbc.co.uk↵
↵
{↵
  "total": 1,↵
  "start_index": 1,↵
  "tags": [↵
    {↵
      "title": "PM",↵
      "time": "2011-08-02T17:22:08+01:00",↵
      "description": "Eddie Mair presents the day's top stories.",↵
      "service": { "id": "0.c224.ce15.ce1.dab", "name": "BBC Radio 4" },↵
      "image_url": "http://radiotag.bbc.co.uk/images/episode/b012wjd3_150_84.jpg",↵
      "link_url": "http://www.bbc.co.uk/programmes/b012wjd3?t=1328"↵
    }↵
  ]↵
}

This could be extended to submissions too. Some examples:

POST /tag HTTP/1.1↵
Content-Length: ?↵
Content-Type: application/json↵
Host: radiotag.bbc.co.uk↵
↵
{ "station": "0.c224.ce15.ce1.dab", "time": 1312301004 }

There has been some suggestion of looking at the work undertaken in TV Tag with regard to a "register ahead of use" flow.

I still feel registration triggered by user intent is the best way to begin the process, as we did in the previous RadioTAG draft. Otherwise we get in to a "Why should I register?" situation with the user.

As a compromise, we could offer the option to enable "lookahead" should a manufacturer wish to add this facility. One possibility is to offer an endpoint to discover registration eligibility. This could either be: 1) Hit /tag without any parameters and observe the WWW-Authenticate headers or 2) create a new endpoint /status which returns either an OK or a Unauthorized with relevant WWW-Authenticate header.

This borders on being "larger" than just tag, it might be worth escalating this as an issue with the CPA group.

Related to #5, if 'Tag' is such a contentious issue - should we either come up with a new name/icon/visual identifier for the button, or at least advise how it should be referred to, or leave it up to manufacturers to implement.

One exception I can vaguely see worthwhile to #4 is a way in the specification for the service provider to advertise an alternative name (and icon?) for the button for suitable UIs. We'd always have a default (maybe still "Tag" or "Mark" or "Favourite") and an icon (I'm still thinking a star).

But being adaptable (on compatiable device types) could allow the BBC, for example, to signal the button to be titled "Playlister" on their music networks and signal a suitable image asset of the Playlister logo. Smartphone apps or hybrid radios with colour touch screens could then show a Playlister button in place of Tag. I feel it would have to be an entirely optional part of the specification, both for client and server implementations.

Earlier tag specifications had some thought put in to how the application could work with AOD. I'd like to revisit this (with reasonable support).

Essentially, the previous specification replaced the broadcast parameters with a URI (something to identify which audio we're talking about) and an offset in seconds from the beginning of the audio.