jdoering;506203 Wrote: > > Actually on second thought; it's another example of why the current > alarm model is weird for smart squeezeboxes. I've followed the thread on > that a bit but haven't digested it all. But the whole idea of the server > "sending" an alarm signal sounds very silly. The radio is a smart device > that could ideally keep it's own time very accurately via NTP. It can > keep track of when alarms should sound without any intervention from the > server. The only thing it should go to the server for is to get the > actual audio at the correct time. If the server can't provide the data > then the local fallback sound plays. But it's the same local logic > driving the alarm either way. > > If the server wants to schedule an alarm it should submit the scheduled > alarm to the Radio at scheduling time. That way the actual alarm is > always local. If the server can't reach the radio to submit the > scheduling then the operation should fail so the user immediately knows > their alarm didn't work. Legacy thin-clients aside; I'm not sure why the > alarms and radio time in general can't work this independently. > > But I'm not trying to turn this thread into another alarm issue rehash > :) > > -Jeff
Your points about how alarms function for the smart devices are right on the money, Jeff. Though the software model used for the new generation of devices certainly changed, it seems as though the software architecture wasn't necessarily reconsidered at the proper depth (at least in the context of certain system functions - alarms being a primary example). With the advent of more intelligence on the client side (which is indeed being utilized in many ways), some of these weird architectural decisions (whether leveraged from legacy thin device operation or not) may be responsible for certain problems that will be hard to get resolved. When the messaging model and architecture aren't carefully scrutinized/considered in advance, a client/server application can get woefully stuck in a maintenance quagmire as issues are incrementally patched up with band-aids. When/if the architecture isn't right to start, stability is not likely to be achieved this way. More likely is a spiral into instability, actually, as the failure cases become more complex... Marc -- Marc ------------------------------------------------------------------------ Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73808 _______________________________________________ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
