RadioVIS application for Leeds Student Radio

[Dylan Jones]

Hello!

My name is Dylan Jones and I am an Electronics student at Leeds making a Hybrid Radio implementing RadioDNS for my final project. I hope you don't mind me jumping in on this mailing list but I am starting to put together a RadioVIS application for the student radio station here at Leeds.

LSRfm currently broadcasts online only and the draft spec (the latest draft I could find: RVIS01 V1.1.0-DRAFT 2011-05) does not define a method for obtaining visual content for IP only services. The RadioEPG spec does however define the broadcast parameters to be given as "id/<service-identifier>" - is this going to be the same then for RadioVIS? ie allowing you construct a topic, for example "/topic/id/lsrfm/text"?

Cheers,

Dylan

[Ben Poor]

Hi Dylan,

Glad to have you aboard!

We're in a slightly odd situation in that the latest posted version of the draft specification doesnt include the IP streaming bits - but it seems you've gotten the right idea from RadioEPG.

The RadioVIS draft I'm working on indeed gives the format that you've hit upon. I've heard no dissent over this, and we're due for ratification relatively soon, so I'd say go ahead and use that. I'll be posting the spec on the list imminently.

Good luck with the project and all that, be great to see what you end up with, and feel free to use the group for any questions.

Ben

[Dylan Jones]

Hello!

I have been making good progress implementing RadioEPG and VIS for Leeds Student Radio but have a quick query...

I am currently using Apache Apollo as the message broker for LSR, there was an initial issue with it not supporting forward slashes within a topic but this was successfully resolved with a fix allowing you to specify an alternate path separator.. with the proposed spec requiring both the FQDN and service-identifier being apart of the topic - we will always have a period within the topic ie /topic/lsrfm.com/lsr/text - has anyone got a solution to specify a topic with both forward slashes and periods with Apache Apollo? Is this another bug to be reported or am I missing a solution?

Dylan

[Pete Redhead]

Hi Dylan,

Looking at the Apollo manual (and a quick skim through the source), the path_separator in the config file should override the default '.' value.
i.e. If you set the path_separator to '/' it should split only on the slashes, as required by the RadioVIS spec.

If you are finding that the broker is splitting the topic on both periods and slashes, then this is a bug which would need raising with the Apollo team.

Best wishes,
Pete

[Dylan Jones]

Hi Pete,

It seems you can only define the topics in the config file using periods (eg: "fm.ce1.c201.08970") - if you use a slash, you get an error (Invalid destination id 'id/lsrfm.com/text')

Even when you define the path_separator value to be a slash, you still have to use a period to define the topics so it looks like you cannot use both simultaneously like we need to. I will raise this as an issue with them.

Thanks,

Dylan

[Andy Buckingham (RadioDNS)]

Chipping in with a dumb suggestion (but hey, it might just work!)

Can you escape the periods so it knows you're not using them as separators?

Something like id.lsrfm\.com.text ?

A

[Pete Redhead]

Hi Dylan,

Looking again at the code (on a boring train journey, so have some free time), it appears that when the broker configures the destinations, it calls the decode_path method on the destination path.

The decode_path method does a regex split on the path looking for full stops (code below). I've tried escaping the full stop, as Andy suggests, but it still splits (and leaves the escape characters in).

If this is going to be a problem that affects multiple implementations of STOMP servers, is it worth considering amending the RadioVIS spec to state that ALL non-alphanumeric characters in the FQDN need to be encoded? e.g. /topic/id/lsrfm%2Ecom/lsrfm/text ?

I would still suggest raising this as a bug in Apollo, as it does not feel to me like this should be the expected behaviour when using the path_separator parameter.

Cheers,

Pete



Router.scala
val DOT_PATTERN = Pattern.compile("\\.");

def decode_path(value:String) = {
  val rc = ListBuffer[Part]()
  for (p <- DOT_PATTERN.split(value)) {
    rc += (if( p startsWith "*" ) {
      if( p.length()==1 ) {
        AnyChildPart
      } else if ( p=="**" ) {
        AnyDescendantPart
      } else {
        val regex_text = unescape(p.substring(1))
        RegexChildPart(Pattern.compile(regex_text))
      }
    } else {
      LiteralPart(unescape(p))
    })
  }
  new Path(rc.toList)

[Ben Poor]

Oh gosh is that code extract Scala? my, there are an awful lot of curly braces in there. <troll>Still, its more comprehensible than Erlang </troll>...

More seriously - this is a good point - we dont yet have a comprehensive view of how other brokers treat paths although I think in this instance this can be considered a shortcoming in Apollo, as Pete suggests.

It might still be worth considering whether non-alphanumeric characters should be URL encoded in this particular topic format. Questions though:

* Are there any brokers that bork when finding things like percentage signs

* Is this a good thing to do when considering non-ASCII domain names? No reason we shouldnt support Chinese domains, for instance.

Luckily we've used URL encoding in a previous incarnation of the IP topic construction in the past (i.e. the 1.0 specification URL encoded the stream URL).

Quick thoughts if we can, and then perhaps I could raise it as a proposal for feedback - obviously we're fairly close to the wire with specification approval here.

Ben

[Sam Starling]

Hi Dylan,

It was me who raised a bug for this originally - you might want to
reference it if/when you raise a new issue. Find it here:
https://issues.apache.org/jira/browse/APLO-6. If I recall correctly,
the fix worked fine - but I never tried it with topics that contained
a full stop.

Sam Starling

On 9 April 2012 14:20, Pete Redhead <peter...@googlemail.com> wrote:

[Dylan Jones]

The Apollo documentation even states in it's very last paragraph that a period is allowed within the destination name -http://activemq.apache.org/apollo/documentation/user-manual.html#Destination_Name_Restrictions - so it seems this is a bug. Thank you all for your assistance. 

Dylan

[Ben Poor]

If this is going to be a problem that affects multiple implementations of STOMP servers, is it worth considering amending the RadioVIS spec to state that ALL non-alphanumeric characters in the FQDN need to be encoded? e.g. /topic/id/lsrfm%2Ecom/lsrfm/text ?

I've had a bit more of a look into this. Whilst we *did* have URL encoded stream URLs in the previous incarnation of IP topic construction (1.0 spec), that was primarily because it is a necessity to have all character types in a URL, including the '/' character which is obviously a problem for topics.

In domains we have a far tighter set of characters, and we also define a Stomp frame as being UTF-8 so we (I believe) allow non-ASCII domain names.

Therefore, I would conclude that no changes are necessary to the specification, and any issues will be specific to the server used.

Ben