[mythtv] Caller ID

[Shawn Rutledge]

--- Ken Bass <kbass at kenbass.com> wrote:
> 1) I wanted my design to interface directly to a caller id modem.
> Your
> design requires the user to apply a patch to the 'mgetty' package. I
> didn't
> want that. 

As I said before, I planned to write one like that.  You could've just
asked me to please finish it so you can use it.

> 2) Your design created an XML telephone event structure that was
> specific to
> caller id and would require myth to understand that structure. I
> wanted a
> generic notify capability that works with stuff other than caller id
> and
> doesn't require any knowledge on the mythtv side (minimize coupling).
> My
> design creates a <mythnotify> XML structure than can allow any
> container/textarea to be updated that exists within an OSD theme.

Well it sounds like yours is specific to Myth then.  It's very easy to
imagine a variety of clients which could display notifications, besides
Myth.  I think XML should always annotate the nature of the content
itself, not specify how to display it.  "textarea" is rather like HTML
in this regard, specifying a method of display; and HTML is being
deprecated in favor of XML in many circles for just this reason.

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
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