The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Audio Control schema changes


  • Subject: Re: Audio Control schema changes
  • From: Michael McSharry
  • Date: Tue, 17 Feb 2004 20:14:00 +0000

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<TITLE>Message</TITLE>
<DIV><FONT face="Arial" size="2">I'll go
with the flow.&nbsp; I'm just jumping in mid-stream without the history
of how the protocol has evolved.&nbsp; My analogy, has to do with the
protocol design rather than with the actual data.&nbsp; Once a load of
apps have been implemented that flood the network then it becomes difficult
to redesign the protocol to make it more efficient because of all of the
legacy implementations.</FONT></DIV>
<BLOCKQUOTE>
<DIV>----- Original Message ----- </DIV>
<DIV><B>From:</B> <A title="lists@xxxxxxx"
href="mailto:lists@xxxxxxx";>Kevin
Hawkins</A> </DIV>
<DIV><B>To:</B> <A
title="xAP_developer@xxxxxxx" href="mailto:xAP_developer@xxxxxxx";>xAP_developer@xxxxxxx</A>
</DIV>
<DIV><B>Sent:</B> Tuesday, February 17, 2004 10:15
AM</DIV>
<DIV><B>Subject:</B> RE: [xAP_developer] Audio Control
schema changes</DIV>
<DIV></DIV>
<DIV dir="ltr" align="left"><FONT
face="Arial" color="#0000ff"
size="2"></FONT>&nbsp;</DIV><FONT
face="Arial" color="#0000ff"
size="2"></FONT>
<BLOCKQUOTE dir="ltr">
<DIV class="OutlookMessageHeader" lang="en-us"
dir="ltr" align="left">
<HR tabIndex="-1">
<FONT face="Tahoma"
size="2"><B>From:</B> Michael McSharry [mailto:mcs101main@xxxxxxx]
<B>Sent:</B> 17 February 2004 16:44<B>To:</B> <A
href="mailto:xAP_developer@xxxxxxx";>xAP_developer@xxxxxxx</A><B>Subject:</B>
Re: [xAP_developer] Audio Control schema changes</FONT></DIV>
<DIV></DIV>
<DIV><FONT face="Arial"><FONT
size="2">It really does not matter to me about the mechanism
of the query.&nbsp; I'll make use of whatever is available from the
provider.&nbsp; I agree that the Now.Playing is a preferred solution
when it becomes available.&nbsp;&nbsp;<FONT
color="#0000ff"><SPAN
class="480085717-17022004">&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face="Arial"><FONT
size="2"><FONT color="#0000ff"><SPAN
class="480085717-17022004"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face="Arial"><FONT
size="2"><FONT color="#0000ff"><SPAN
class="480085717-17022004">It's nearer than it was before
:-)&nbsp;&nbsp;</SPAN><SPAN
class="480085717-17022004">&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face="Arial"><FONT
size="2"><SPAN
class="480085717-17022004"></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face="Arial" size="2">I don't
like the idea of periodic info messages floating all over the network when
there is no receiver actually wanting them.&nbsp; A query based upon a
target's need is generally a more efficient mechanism to induce a message
notification than an internal timer at the source.<SPAN
class="480085717-17022004"><FONT
color="#0000ff">&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><FONT face="Arial" size="2"><SPAN
class="480085717-17022004"></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Arial" color="#0000ff"
size="2"><SPAN class="480085717-17022004">The
design concept&nbsp;of xAP means that you are not aware what (if
anything) is listening so you do need to provide such information.
A&nbsp;contrast&nbsp;is that when info is needed by several devices
they don't each have to ask for it.&nbsp;Cache systems and controllers
can also monitor passively.&nbsp;Timers are not&nbsp;typically used
to provide this periodic reporting/status - a xAP implementation would by
choice only broadcast new data when an 'event' had occurred
that&nbsp;superceded the&nbsp;validity of the last&nbsp;data
sent&nbsp;- this is not always true as the implementation is under the
developers control of course. Once point to point dependencies get set up
then you drift towards a need to know exactly where things are located and
you get software locks appearing when a service is unavailable.&nbsp;
In practica
lity the volume of traffic certainly on an Ethernet connection is many
orders of magnitude from being&nbsp;significant
anyway</SPAN></FONT></DIV>
<DIV><FONT face="Arial" color="#0000ff"
size="2"><SPAN
class="480085717-17022004"></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT size="2"><SPAN
class="480085717-17022004">&nbsp;</SPAN>&nbsp;
If a target does want periodic updates then a request mechanism could exist
in the schema where the query parameter includes the frequency
of&nbsp;response where the default is once.&nbsp; I am sensitive to
garbage that pollutes the network.&nbsp; As garbage gets old it starts
stinking and then it is a mess to clean up.<SPAN
class="480085717-17022004"><FONT
color="#0000ff">&nbsp;</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT size="2"><SPAN
class="480085717-17022004"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT size="2"><SPAN
class="480085717-17022004"><FONT
color="#0000ff">A rather&nbsp;loaded analogy as all data
is transient&nbsp;- a polling scenario, particularly of the frequency
of MSC Music which I think defaulted to every 2 seconds or so generates
</FONT>&nbsp;<FONT color="#0000ff">a
comparitively large volume of such 'garbage' as far as other receivers are
concerned so I feel event&nbsp;triggered is absolutely the right
approach.</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT color="#0000ff"
size="2"><SPAN
class="480085717-17022004"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT color="#0000ff"
size="2"><SPAN class="480085717-17022004">The
Slim CLI interface implementation&nbsp;is
very&nbsp;verbose&nbsp;when utilised in an event triggered
mode</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT color="#0000ff"
size="2"><SPAN
class="480085717-17022004"></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size="+0"><FONT
face="Arial"><FONT color="#0000ff"
size="2"><SPAN
class="480085717-17022004">&nbsp;&nbsp;&nbsp;
Kevin</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BLOCKQUOTE>




xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.