[mythtv] Caller ID

Kevin Elliott kevin at phunc.com
Thu Sep 18 21:54:28 EDT 2003


> The entirety of a "caller ID" notification packet is, in fact, about a
> Caller ID event.  If you want to send other kinds of notifications on
> the same UDP port, there's nothing stopping you from doing it; and
> clients which are interested only in caller ID info can look at the
> first tagname within the packet to decide whether they're interested or

Certainly you're not referring to the initial block. The initial block
should almost always be a container tag describing the generic contents
of the xml content within.

Frankly, I think creating a higher level mythrequest protocol would be
more appropriate, to facilitate for future advancements in the rpc 
(i.e. controlling myth remotely, other forms of rpc like data fetching,
web services, etc)

For example:

<MythRequest version="1.0">
  <alerts>
    <alert type="callerId">
      <name>Jack Johnson</name>
      <phoneNumber>650 444 4444</phone>
    </alert>
    <alert type="message" delay="5">
     <message>You have received 5 unanswered phone calls today</message>
    </alert>
  </alerts>
  <execCommand name="flushLogs"/>
</MythRequest>

> not.  You can have other packets flying around with other tagnames for
> other kinds of notifications, and some clients will be interested in
> more of them than others.  And if you want to build a universal client
> that can display every kind of notification, you could use some kind of
> downloadable transforming code, like XSLT for example; or you could
> write code which just puts up a labeled field for every element and
> every attribute, without caring what they are.  (But that would
> probably create a somewhat cluttered UI, so it would be better to use a
> specific transformer if possible, and fall back to the universal
> display code if not.)  That way the packet content can be a fixed
> standard: if it semantically identifies each data item and attribute,
> and makes sense, then it is complete; and you can be free to change the
> transforms to display it in different ways.
> 
> > 3) Your design hardcoded the XML structure in the cidbcast program,
> > mine
> > reads it from a file and replaces keywords. This allows changing the
> > XML
> > structure without changing the program.
> 
> In practice it's hard to change the structure of the XML once clients
> have been written, because they tend to hard-code the parsing of the
> XML.
> 
> Like I said before, to get the greatest flexibility, the receiver
> shouldn't be built-in to Myth anyway; there should be a command-line
> method to put up arbitrary OSD's on Myth, and the receiver should be a
> separate process (or shared-library "plugin" or something like that)
> which listens to UDP packets and then calls Myth with the data to
> display.  Then you could have OSD's about events which come from other
> sources besides UDP ("CPU temperature out of range" is a good example).
>  
> 
> The external listener could do the transformation from data-oriented
> XML to some kind of display-oriented form.  It could just generate a
> command line like this:
> 
> mythosd --title="Incoming phone call" --name="Joe Blow"
> --number="1-888-555-1212" 
> 
> and mythosd would extract the title and treat it specially, and for
> every other parameter it would display the key and the value as labeled
> text fields.  Or, if you prefer, you could generate display-oriented
> XML and hand that across to Myth:
> 
> <osd title="Incoming phone call">
>   <field name="Name">Joe Blow</field>
>   <field name="Number">1-888-555-1212</field>
> </osd>
> 
> It's every bit as generic, for describing the content of an on-screen
> display, and it's Myth-specific, which might be appropriate for Myth,
> but this form of data does not belong in a UDP packet.
> 
> And then there could be a temperature-monitoring daemon which uses the
> same interface to put up OSD's when the CPU gets dangerously hot, and
> another daemon which does notifications about something else, and so
> on.
> 
> > 4) My design wanted command line argument of all parameters (change
> > the UDP
> > port # (--udp_port=xxxx), change the broadcat address
> > (--bcast=192.168.1.255), etc.
> 
> That's a small change that I would be glad to do in my sender.
> 
> I have not written any Myth code before.  If you have figured out how
> to put up on-screen displays, then I think you should write the code to
> do that, and I will write the listener to convert my caller ID packets
> to whatever form the OSD code wants, and we can collaborate on a sender
> which is independent of mgetty.  Then we will have interoperability,
> and we won't have Myth listening on a port itself.
> 
> 
> =====
> . _______  Shawn T. Rutledge / KB7PWD ecloud at bigfoot.com
>  (_  | |_)    http://ecloud.org/  kb7pwd at kb7pwd.ampr.org
>  __) | | \______________________________________________
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev



More information about the mythtv-dev mailing list