Choosing priority between RadioVIS and DAB MOT slideshow services
Robin Cooksey
Hi,
The current RadioVIS specification (1.1) defines a what is effectively a parallel IP-based implementation for DAB slideshow, but I don’t believe it really addresses the issue of how a receiver should choose betwen them if both RadioVIS and DAB slideshow are available. It also doesn't cover how a broadcaster could signal their intent or preference.
One approach that could be taken would be to simply allow DAB MOT slideshow to always take priority over RadioVIS - i.e. assume that receiving slides via broadcast rather than using IP would always be preferred.
If the RadioVIS service is exactly equivalent to the DAB MOT slideshow service (containing identical slides, with identical rotation), then this would probably be perfect behaviour - it would be the same user experience, but received over broadcast, not IP.
However, if broadcast MOT slideshow and RadioVIS services are not equivalent - for example, the MOT slideshow is available only with a very limited bandwidth, then using RadioVIS might give a better user experience where it's available. The limited bandwidth MOT slideshow is still useful to give a better user experience on devices which do not support RadioVIS, or when RadioVIS is not available - e.g. there's no network connectivity at the time.
So, it would be useful for the relative priorities of the DAB MOT slideshow and RadioVIS slideshows to be signalled by the broadcaster, in the case that they're both available.
There's a proposal that this can be achieved by attaching some extra meaning to the priority field of the SRV records which indicate RadioVIS availability (radiovis and radiovis-http).
Specifically, if the priority field is less than 100, the broadcaster is indicating that the RadioVIS service should be preferred over MOT slideshow, and if the priority field is >= 100, MOT slideshow should be preferred.
In effect, DAB MOT slideshow could be considered as having an implicit priority of 100.
Does anyone have any thoughts on this?
I think the intention would be to specify this logic in a future revision of the RadioVIS specification.
Best regards,
Robin
Robin Cooksey
Principal Software Engineer, Frontier Silicon Ltd.
Dales Manor Business Park, Babraham Road, Sawston, Cambridge, CB22 3LJ, UK
Tel: +44 1223 497784, Fax: +44 1223 836761
Frontier Silicon Limited is a company registered in England and Wales with company number 4213838. Registered address: 137 Euston Road, London, NW1 2AA, UK.
James Cridland
DAB MOT gives me generic slides; RadioVIS gives me slides which can be Geo-aware (based on IP) - therefore, in the UK for example, tuning into a national SFN service like Planet Rock, a listener might get local weather and traffic on RadioVIS, which would be impossible on DAB MOT. In essence, RadioVIS can personally enhance generic visuals delivered via broadcast.
--
Where new platforms and radio collide: http://james.cridland.net/blog/
Nick Piggott (RadioDNS)
It's not what Priority was designed to do, so I would prefer to maybe find some other two bit indicator, assuming there's agreement this would be a helpful solution.
Robin Cooksey
Hi James,
Good point – the proposal focussed on what to do with the image topic, and ignored the text topic.
The current implementation of Frontier Silicon based radios with RadioVIS is to always use the text from DAB DLS (or from RDS RadioText for FM) – not from RadioVIS.
Is there likely to be any link or dependency between the preferred choice of source for images and text? E.g. would it be reasonable to rule out the possibility of a broadcaster indicating that they prefer a device to use RadioVIS for text, but not for images?
If so, I think it could be solved by defining DAB DLS text as having an implicit priority of 50.
So, for:
· 0 <= priority < 50, the broadcaster is signalling that RadioVIS is preferred for both text and images
· 50 <= priority < 100, RadioVIS is preferred for images, but DAB DLS for text
· Priority >= 100, DAB DLS and MOT slideshow both preferred over RadioVIS
This doesn’t allow for every possibility, but without changing the meaning of the priority field from a linear priority (as Nick has suggested in another reply), it’s not obvious how every possibility could be catered for.
Also, what about FM RDS RadioText? In this case, the maximum length is 64 bytes (as opposed to 128 for DAB DLS), so there’s another reason why RadioVIS text might be preferred – as it could give a better user experience.
Best regards,
Robin
James Cridland
Robin Cooksey
I’d be concerned about using the SRV priority in that way. As Nick pointed out, it’s not what the priority was designed to do.
While the easy route you mention ignores other platforms, are there any other platforms that have equally limited text capability, or is FM effectively a special case in having a limit of 64 bytes in text messages?
Is it even necessary to separate out text and images, or is it sufficient to just say that text from RadioVIS is preferred, if RadioVIS is also being used for images? I.e. the text preference essentially automatically follows the image preference.
This would mean that if DAB MOT slideshow is being used, then DAB DLS will also be used (so text alone would not be retrieved from RadioVIS in the presence of MOT slideshow); and it would mean that text from RadioVIS might be used, even when it’s identical to the DAB DLS.
However, is it reasonable to assume that the additional overhead of text from RadioVIS is not that significant when images from RadioVIS are already being used?
I think we should convince ourselves that any additional flexibility is worth the additional complexity that it would require, in terms of specifying, and then implementing, testing and maintaining it.
Andy Buckingham (RadioDNS)
separate text out from VIS and that one should imply the other. The
bandwidth saving for using DLS over SRV is pretty minimal, even when
considering cellular data services.
We must also keep in consideration the fact that the priority is
designed to alter the order a client users multiple servers providing
the same functionality, so that services can be load balanced.
Numerical ordering across all records is important.
A
James Cridland
Andy Buckingham (RadioDNS)
But it does significantly raise the barrier of entry and we get in to
a discussion about whether EPG support is mandatory or recommended for
VIS.
Robin Cooksey
However, in the specific case of choosing between RadioVIS images and DAB MOT slideshow, I still feel that using the SRV priority field (DAB MOT slideshow having an implicit priority of 100) is probably a good solution.
The further complexity of what to do with RadioVIS text is potentially a problem - but (given the relatively smaller additional overhead) can probably be dealt with by just making that decision follow the images.
James Cridland
But it does significantly raise the barrier of entry and we get in to
a discussion about whether EPG support is mandatory or recommended for
VIS.
Robin Cooksey
Hi James,
I’m not sure that the status quo right now is "if you have RadioVIS, the receiver ignores broadcast and uses RadioVIS" – I think it’s more like “if you have RadioVIS, the receiver will only use it if you don’t have MOT slideshow”.
However, as the priority isn’t actually defined currently – it’s currently up to the receiver manufacturers what priority they take, without any way for a broadcaster to signal their preference.
Do you have any specific objection to the use of the SRV priority field for signalling this preference (other than the limitation of not covering the text case)?
James Cridland
I’m not sure that the status quo right now is "if you have RadioVIS, the receiver ignores broadcast and uses RadioVIS" – I think it’s more like “if you have RadioVIS, the receiver will only use it if you don’t have MOT slideshow”.
However, as the priority isn’t actually defined currently – it’s currently up to the receiver manufacturers what priority they take, without any way for a broadcaster to signal their preference.
Ben Poor
The information in this email and any of its attachments is intended solely for the addressees and is confidential. If you receive this message in error, please immediately notify the sender, destroy any copies and delete it from your computer system.
The contents may contain information which is confidential and may also be privileged. Any part of this email may not be used, disseminated, forwarded, printed or copied without authorisation.
Liability cannot be accepted for any statements, views or opinions made which are clearly the sender's own and not expressly made on behalf of any of the companies below.
Global Radio UK Ltd (6251684) / Global Radio Holdings Ltd (4077052) / This is Global Ltd (6288359) / Global Radio Ltd (923454) / Global Radio Services Ltd (3296557) / Global Talent Group Ltd (3601691) / Global Talent Management Ltd (4631297) / Global Talent Music Ltd (5522116) / Global Talent Publishing Ltd (3509421) / Global Talent TV Ltd (4506139) / Global Talent Records Ltd (3598411) / Global Charities Ltd (4359098) Registered Office: 30 Leicester Square, London WC2H 7LA
Nick Piggott (RadioDNS)
>> On 28 June 2012 13:56, Robin Cooksey <Robin.Cooksey@frontier-silicon.com>
>> > To: radiovis-developers@googlegroups.com
Robin Cooksey
Hi,
Nick – thank you for your thoughts, even if it does spoil our fun of inventing technical solutions to an ill-defined problem!
Maybe it would be useful if I re-state the original issue, and we consider that problem and the requirements of a solution first.
The original issue was that the existing RadioVIS 1.1 (and 1.0) specification does not address the issue of how a receiver should choose between RadioVIS and DAB MOT slideshow, if both are available for the same station. It’s currently left up to the receiver implementation to decide, and it seems that different receiver implementations may have taken different approaches.
There are already existing examples where it’s likely that the broadcaster would prefer one of the other two take precedence (e.g. where the services are equivalent, DAB MOT might be preferred as it has no bandwidth cost; and where the DAB MOT service is basic, RadioVIS might be preferred as it’s a better user experience). There are also suggestions for other future uses of RadioVIS (e.g. localisation) where a broadcaster might prefer RadioVIS over DAB MOT slideshow.
In addition to this choice between RadioVIS (image topic) and DAB MOT slideshow, James also raised a similar question about the RadioVIS text topic and DAB DLS – and whether there are similar priority issues there.
As we’ve shown so far in this discussion, it’s clearly possible to come up with technical solutions that solve any of these problems; but as Nick suggests it would be useful to first examine the problem, and agree what the requirements of that solution should be.
I can see the following possible options:
1) For the RadioVIS image topic:
a) Do nothing – leave it up to the receiver manufacturer how to prioritise between RadioVIS and DAB MOT slideshow.
b) Define an agreed static priority in the RadioVIS specification (e.g. that RadioVIS is always used in preference to DAB MOT slideshow, or vice versa).
c) Define a mechanism for a broadcaster to statically publish their preferred priority – e.g. a static mechanism where the priority is not expected to change often (if at all).
d) Define a mechanism to allow the broadcaster to dynamically publish their preferred priority – where the relative priority of the two services could change at certain times (either on a fixed schedule, or by signalling it dynamically).
2) For the RadioVIS text topic:
a) Do nothing – again leave it to the receiver manufacturer (as above).
b) Define a static priority in the RadioVIS specification (as above).
c) Specify that the RadioVIS text topic follows the image topic. I.e. the if RadioVIS is being used for images, it should also be used for text; otherwise RadioVIS should not be used for text.
d) Define some mechanism for the broadcaster to signal their preference for a station, independently from the image topic.
Does anyone have any thoughts on how much of a problem this actually is, and which of the above options would sufficiently solve the problem?
I think we should bear in mind that while we can easily create a complex and powerful technical solution, it is probably much better to create a sufficient solution that solves the problem without burdening the specification and implementations with complex mechanisms that may never actually need to be used.
I’d welcome any further feedback on this – and once we’ve agreed a consensus on the requirements, we can return to the technical solutions.
Best regards,
Robin
From: radiovis-...@googlegroups.com [mailto:radiovis-...@googlegroups.com]
On Behalf Of Nick Piggott (RadioDNS)
Sent: 30 June 2012 13:03
To: radiovis-...@googlegroups.com
Subject: Re: Choosing priority between RadioVIS and DAB MOT slideshow services
Hi all,
I think we should be careful about considering what could be achieved by bending various existing parameters/meta-data/specs before we've concluded what's required, and got a sense of proportion into the scale of the problem posed.
Whilst I'm aware I'm guilty of contributing a "quick fix" up the top there, the requirements have grown a bit since then, and so the proposals for solutions have become more complex.
If there's a perception of a problem of sufficient size/value that warrants inspection, then can we just formalise that inspection and conclusion a bit more?
Thanks,
Nick
London WC2H 7LA
Pete Redhead
I have one more point which I feel would be worth adding to the considerations above.
Whilst a broadcaster may prefer a client to consume slides from one medium over another, I think it is important to allow the client to make an informed decision too.
A listener with a mobile device would probably be very happy for it to take RadioVIS slides whilst connected via Wi-Fi, but would probably take issue with the extra bandwidth used when on a 3G connection and would be better served say by DAB MOT slideshow. Therefore the device should be able to make an informed decision on where to acquire slides from based on what kind of Internet connection it currently has.
I'm not sure how this would fit in the suggestions above - maybe override it or apply an adjustment to the cost of each source.
Pete
Robin Cooksey
Hi Pete,
Yes – this is a good point.
I think this is the kind of thing I was getting at by referring to a broadcasters “preferred priority” – it’s probably only one factor that a receiver should take into account here.
So, I think it’s worth bearing in mind this perspective when considering the options above.
Robin Cooksey
Hi All,
As there have been no other follow-ups to this (other than Pete’s point about the client being able to make an informed decision), I thought I would add my thoughts on the suggested options below:
> 1) For the RadioVIS image topic:
> a) Do nothing – leave it up to the receiver manufacturer how to prioritise between RadioVIS and DAB MOT slideshow.
This is the current status quo, but I think common consensus was that it would be better to provide more information to the receiver manufacturer to help them make this decision – it seems that there is already some variation between how different products behave.
> b) Define an agreed static priority in the RadioVIS specification (e.g. that RadioVIS is always used in preference to DAB MOT slideshow, or vice versa).
It’s easy to point to different examples where the broadcaster’s preference would be one or the other – so I suspect it would be difficult to agree a single static defined priority.
> c) Define a mechanism for a broadcaster to statically publish their preferred priority – e.g. a static mechanism where the priority is not expected to change often (if at all).
This option would allow the broadcaster’s preference for a given service to be made available to the receiver manufacturer – to help them make an informed decision.
> d) Define a mechanism to allow the broadcaster to dynamically publish their preferred priority – where the relative priority of the two services could change at certain times (either on a fixed schedule, or by signalling it dynamically).
I don’t believe that anyone has proposed a use-case where the priority may need to change dynamically – and this would be a further complication. I think it’s agreed that it’s important not to make things more complicated than they need to be, to help keep the barrier to entry low.
So, I think that the requirement for the RadioVIS image topic may be c) – define a mechanism for the broadcaster to statically publish their preferred priority.
Does anyone disagree with this conclusion – or have any further comments to add?
> 2) For the RadioVIS text topic:
>a) Do nothing – again leave it to the receiver manufacturer (as above).
> b) Define a static priority in the RadioVIS specification (as above).
> c) Specify that the RadioVIS text topic follows the image topic. I.e. the if RadioVIS is being used for images, it should also be used for text; otherwise RadioVIS should not be used for text.
> d) Define some mechanism for the broadcaster to signal their preference for a station, independently from the image topic.
Of these options, I believe that c) may be the most appropriate.
I feel that if the priority for the RadioVIS image topic is being defined in some way, then the text topic cannot simply be ignored – it should also be addressed in some way; so I think this rules out a).
The costs and downsides of fetching the text via IP are lower than for images – as the bandwidth required for the data is so much smaller. So, if RadioVIS is being used for images, then there is not much downside to using it for text as well.
Conversely, the benefits of using RadioVIS rather than the broadcast text are also not likely to be great – with two exceptions that have been noted so far:
i) For FM stations, the RDS RadioText is limited to 64 characters, as opposed to 128 characters for RadioVIS – so using RadioVIS would allow longer messages.
ii) Also, using RadioVIS might allow some localisation which isn’t possible for national broadcasts.
So, I think that option c) (RadioVIS is used for text if it’s also being used for images) would be the most appropriate solution. There is not much downside of using RadioVIS for text, when it’s already being used for images.
For issue i) above, FM will not have any slideshow – so RadioVIS will be used for images, and therefore also used for text.
For issue ii), if a broadcaster is providing localised text, it’s probable that they may also want to provide localised images – in which case they would signal that RadioVIS is preferred for images, so it would also be used for text.
If these assumptions are all correct, I think that the requirement for the RadioVIS text topic may be c) – the RadioVIS text topic follows the image topic.
Therefore, my conclusion is:
1) For the RadioVIS image topic:
c) Define a mechanism for a broadcaster to statically publish their preferred priority – e.g. a static mechanism where the priority is not expected to change often (if at all).
2) For the RadioVIS text topic:
c) Specify that the RadioVIS text topic follows the image topic. I.e. the if RadioVIS is being used for images, it should also be used for text; otherwise RadioVIS should not be used for text.
Does anyone have any comments on my reasoning above, or my conclusions?
Alexander Erk
Regards
Alex
Dipl.Inf (FH) Alexander Erk
Informationsdienste
Institut für Rundfunktechnik GmbH
Phone: +49 (0)89 / 323 99 - 282
Fax: +49 (0)89 / 323 99 - 200
Internet: www.irt.de
Research and Development Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstraße 60, 80939 Muenchen, Germany
registration court Munich Commercial, Register No. B 5191
Managing Director: Dr. Klaus Illgner-Fehns
Robin Cooksey
So I think you're essentially suggesting:
iii) RadioVIS may not have a text topic, while it does have image topic.
Allowing further granularity to allow the broadcaster to indicate different preferences for text and image will be likely to add further complication, so I'd rather be sure it's definitely necessary before we tackle that problem.
In the case that you mention, for ARD, presumably the text topic doesn't exist? So, when the receivers tries to subscribe to the text topic, they should receive an error - I don't think it will be necessary to wait for a while before falling back to broadcast.
So, we could say that text follows the image to RadioVIS; with the exception that it subscribing to the text topic causes an error, the receiver should fall back to broadcast for the text only.
Does this sound OK?
Best regards,
Robin
> Sent: 10 July 2012 14:02
> To: radiovis-...@googlegroups.com
> Subject: Re: Choosing priority between RadioVIS and DAB MOT slideshow
> services
>
> Hi all,
>
>
>
> > Hi All,
> >
> > As there have been no other follow-ups to this (other than Pete's point
> about the client being able to make an informed decision), I thought I would
> add my thoughts on the suggested options below:
> >
> > > 1) For the RadioVIS image topic:
> >
> > This is the current status quo, but I think common consensus was that it
> would be better to provide more information to the receiver manufacturer
> >
> > > b) Define an agreed static priority in the RadioVIS specification (e.g. that
> RadioVIS is always used in preference to DAB MOT slideshow, or vice versa).
> >
> > It's easy to point to different examples where the broadcaster's
> >
> > > c) Define a mechanism for a broadcaster to statically publish their
> >
> > This option would allow the broadcaster's preference for a given service to
> >
> > > d) Define a mechanism to allow the broadcaster to dynamically publish
> dynamically).
> >
> > I don't believe that anyone has proposed a use-case where the priority
> than they need to be, to help keep the barrier to entry low.
> >
> >
> priority.
> >
> >
> >
> > > 2) For the RadioVIS text topic:
> >
> > > c) Specify that the RadioVIS text topic follows the image topic. I.e. the if
> RadioVIS is being used for images, it should also be used for text; otherwise
> RadioVIS should not be used for text.
> > > d) Define some mechanism for the broadcaster to signal their preference
> for a station, independently from the image topic.
> >
> > Of these options, I believe that c) may be the most appropriate.
> > I feel that if the priority for the RadioVIS image topic is being defined in
> > The costs and downsides of fetching the text via IP are lower than for
> it for text as well.
> > Conversely, the benefits of using RadioVIS rather than the broadcast text
> > i) For FM stations, the RDS RadioText is limited to 64 characters, as opposed
> > ii) Also, using RadioVIS might allow some localisation which isn't possible for
> national broadcasts.
> >
> > So, I think that option c) (RadioVIS is used for text if it's also being used for
> images) would be the most appropriate solution. There is not much
> downside of using RadioVIS for text, when it's already being used for images.
> > For issue ii), if a broadcaster is providing localised text, it's probable that
> >
> > If these assumptions are all correct, I think that the requirement for the
> >
> >
> > Therefore, my conclusion is:
> > 1) For the RadioVIS image topic:
> > c) Define a mechanism for a broadcaster to statically publish their preferred
> >
> > Maybe it would be useful if I re-state the original issue, and we consider
> that problem and the requirements of a solution first.
> >
> > The original issue was that the existing RadioVIS 1.1 (and 1.0) specification
> does not address the issue of how a receiver should choose between
> RadioVIS and DAB MOT slideshow, if both are available for the same station.
> It's currently left up to the receiver implementation to decide, and it seems
> that different receiver implementations may have taken different
> approaches.
> >
> > There are already existing examples where it's likely that the broadcaster
> would prefer one of the other two take precedence (e.g. where the services
> are equivalent, DAB MOT might be preferred as it has no bandwidth cost;
> and where the DAB MOT service is basic, RadioVIS might be preferred as it's
> a better user experience). There are also suggestions for other future uses
> of RadioVIS (e.g. localisation) where a broadcaster might prefer RadioVIS
> over DAB MOT slideshow.
> >
> > In addition to this choice between RadioVIS (image topic) and DAB MOT
> slideshow, James also raised a similar question about the RadioVIS text topic
> > As we've shown so far in this discussion, it's clearly possible to come up
> with technical solutions that solve any of these problems; but as Nick
> suggests it would be useful to first examine the problem, and agree what the
> requirements of that solution should be.
> >
> > I can see the following possible options:
> >
> > 1) For the RadioVIS image topic:
> > b) Define an agreed static priority in the RadioVIS specification (e.g. that
> RadioVIS is always used in preference to DAB MOT slideshow, or vice versa).
> > c) Define a mechanism for a broadcaster to statically publish their preferred
> > d) Define a mechanism to allow the broadcaster to dynamically publish
> dynamically).
> >
> > 2) For the RadioVIS text topic:
> > c) Specify that the RadioVIS text topic follows the image topic. I.e. the if
> RadioVIS is being used for images, it should also be used for text; otherwise
> RadioVIS should not be used for text.
> > d) Define some mechanism for the broadcaster to signal their preference
> for a station, independently from the image topic.
> >
> >
> > Does anyone have any thoughts on how much of a problem this actually is,
> and which of the above options would sufficiently solve the problem?
> >
> > I think we should bear in mind that while we can easily create a complex
> and powerful technical solution, it is probably much better to create a
> sufficient solution that solves the problem without burdening the
> specification and implementations with complex mechanisms that may never
> actually need to be used.
> >
Alexander Erk
Am 10.07.2012 um 18:28 schrieb Robin Cooksey:
> Hi Alex,
>
> So I think you're essentially suggesting:
> 2) For the RadioVIS text topic:
> d) Define some mechanism for the broadcaster to signal their preference for a station, independently from the image topic.
>
> Because of a third negative reason for using RadioVIS for text, which is:
> iii) RadioVIS may not have a text topic, while it does have image topic.
/topic/<broadcast-parameters>/<content-type>
The content-type should have a value of either image or text.
So the client can register for images and texts separately.
>
> Allowing further granularity to allow the broadcaster to indicate different preferences for text and image will be likely to add further complication, so I'd rather be sure it's definitely necessary before we tackle that problem.
> In the case that you mention, for ARD, presumably the text topic doesn't exist? So, when the receivers tries to subscribe to the text topic, they should receive an error - I don't think it will be necessary to wait for a while before falling back to broadcast.
>
> So, we could say that text follows the image to RadioVIS; with the exception that it subscribing to the text topic causes an error, the receiver should fall back to broadcast for the text only.
For the HTTP transport does this mean that for a request a "404" is the response.
But in general this would mean, that for the text messages the mechanism is a controlled failure of the service subscription. What I don't understand is, if we introduce a mechanism for the image part, why using the same mechanism only for another topic causes more complexity.
Alex
Ben Poor
To the best of my knowledge there is nothing in the specification to define behaviour of a Stomp server in regards of clients registering to topics that may not exist. There is no requirement for a server to send back an error.
For most people using ActiveMQ as their Stomp server, they have their configuration set up to disallow automatic topic creation by client subscription (authenticating anonymously), which will return a Java stack trace to the client when they try to subscribe to a topic that does not yet exist. Given different configuration, or when using another Stomp server, the server may legitimately return nothing when a client subscribes to a topic that does not yet exist, and either do nothing or create that topic automatically.
So we should not be assuming behaviour in this respect.
For the HTTP transport, again nothing is defined in the specification regarding topics not yet created, and precise behaviour left up to the implementor. The server *could* return a 404 to indicate a topic that has not been configured, or not yet created, but may also timeout with no response. This mirrors the expectations put upon an HTTP server - the status codes are there, but behaviour is left up to the implementation.
Robin Cooksey
> > So I think you're essentially suggesting:
> > 2) For the RadioVIS text topic:
> > d) Define some mechanism for the broadcaster to signal their preference
> for a station, independently from the image topic.
> >
> > Because of a third negative reason for using RadioVIS for text, which is:
> > iii) RadioVIS may not have a text topic, while it does have image topic.
>
> I don't understand you here. The RadioVIS spec. says in section "2. Topics":
>
> /topic/<broadcast-parameters>/<content-type>
> The content-type should have a value of either image or text.
>
> So the client can register for images and texts separately.
What I meant was that another possible downside of attempting to use RadioVIS for text is that the broadcaster may not be providing a text topic, although they are proving an image topic.
> >
> > Allowing further granularity to allow the broadcaster to indicate different
> preferences for text and image will be likely to add further complication, so
> I'd rather be sure it's definitely necessary before we tackle that problem.
> > In the case that you mention, for ARD, presumably the text topic doesn't
> exist? So, when the receivers tries to subscribe to the text topic, they should
> receive an error - I don't think it will be necessary to wait for a while before
> falling back to broadcast.
> >
> > So, we could say that text follows the image to RadioVIS; with the
> exception that it subscribing to the text topic causes an error, the receiver
> should fall back to broadcast for the text only.
>
> Ok, in my understanding the STOMP model allows the registration of clients
> on any possible topic and as soon as there is a SEND command for this topic
> the registered clients get this message forwarded. Is it a usual configuration
> option in the STOMP servers, to say that a SUBSCRIBE command ends with an
> ERROR message from the STOMP server?
>
> For the HTTP transport does this mean that for a request a "404" is the
> response.
As you hinted at earlier in the thread, they could wait with a timeout instead.
>
> But in general this would mean, that for the text messages the mechanism is
> a controlled failure of the service subscription. What I don't understand is, if
> we introduce a mechanism for the image part, why using the same
> mechanism only for another topic causes more complexity.
If instead we need to provide two independent preferences, then that simple solution probably won't work - which was why I was preferring to avoid adding an extra method to prioritise text too.
I was previously assuming that simply making the text topic "follow" the image topic to RadioVIS would work, and not have any down-sides - however, I hadn't considered the case where there isn't a RadioVIS text topic.
So, what is the general consensus? Does the text topic need its own independent priority?
Best regards,
Robin