An update from EBU RadioDNS Hackday
Andy Buckingham
what's been happening.
Firstly, you are welcome to read a copy of the update I presented to
the AGM on our team progress so far with Tag. It's hosted on Google
Docs at the following URL:
Of particular note in the update is the proposed Commercial RadioTAG
sub-team. I'll send a separate note to the list about this shortly.
During the RadioDNS Hack Day which preceded the AGM, we setup a small
focus group for those interested in RadioTAG to discuss some of the
recent suggestions and begin to forge a path to our final
specification drafts for 1.0.
We discussed the enforcement of HTTPS and UDI generation based on a
UUID which was met with approval. I'd still appreciate some more
manufacturer representatives that may be lurking in the group to
provide some reassuring noises that this isn't going to cause
headaches at an implementation level for simple clients.
Chris Lowis from the BBC led conversation on the potential to utilise
OAuth for the device/user authentication process. Whilst previously
discounted on the basis that device screens would be unsuitable for
rendering the necessary HTML page for a typical OAuth transaction,
Chris is interested in investigating a simple challenge methodology
with OAuth which may be implementable even on very basic devices. I
believe Chris will be looking in to this further and feeding back to
the team shortly.
We discussed the possibility of extensibility with regards to enabling
proprietary implementations on top of the standardised Tag spec. This
led to discussion on whether we should use something like XML for the
response (and possibly request) bodies so that namespace declarations
could add clearly defined additional fields.
Whilst I believe this is a noble goal for the project, my concern is
that this is a big ambition for 1.0 of the Tag specification. ome form
of light syntax is needed to organised response and ease parsing. JSON
was intentionally chosen in the current draft for its lightweight and
ease of implementation. If interesting and novel uses on top of tag
come up there's nothing to stop organisations implementing them
themselves without complicating the implementation for all with
heavier XML responses and namespace declarations. I'd much rather
encourage those with new ideas to feed them to the team to implement
in the core spec and better tag as a technology for all. How do others
feel on this subject?
It was highlighted that the previously specified multiple tags per
single submission methodology significantly complicated
implementation, having to parse multiple lines of the response to work
out if one of the tags had failed. It also led to complications, as
previous pointed out on this group, when tags from non-linear audio
were included such as podcasts - where should they be positioned
within the tagged events array? Therefore, I believe it worthwhile to
promote the notion that the initial spec will concentrate on one
tagged event per request, and that simply from the HTTP response of
that submission attempt you can ascertain the success/failure, using
status codes such as 201 for tag created etc.
This leads nicely to some discussion around the proposals to make the
submission more "REST'ful". It was already proposed to make the
submission a simple HTTP POST, using query string variables rather
than a JSON body. Further to this, and after discussion last week, I'd
like to put forward a proposal to tweak the URL request in to a format
like:
http://hostname/1.0/<params>/tag
Where params would be 'fm/ce1/c586/09580' for example. This way you
are targeting a resource of tag, organised under the station
hierarchy, rather than a generic "tag" resource then passing station
identifiers as a query string. If you think about it semantically, the
resource is the radio service you are submitting to. The service is
not part of the tag data itself, that's the date/time etc. This seems
cleaner and more organised too me.
Where next? Well, I'd like to allow people a few days to mull over the
above points. Good or bad, I'd appreciate feedback on them all so we
can make some important decisions and move to the next draft of the
specification. I will begin putting the bits together for a new spec
and keep an eye across discussions so we can collectively influence
the contents of the next draft.
Thanks for your time.
Andy.
--
Andy Buckingham,
Global Radio