[mythtv] Caller ID

Shawn Rutledge e_cloud at yahoo.com
Wed Sep 17 17:31:58 EDT 2003


> 1) Say there is a 'mythosd' program. How would the invocation of this
> program communicate with the running myth. Would it use some shared
> memory
> scheme, use a local UDP (non-broadcast), or what?

There are lots of inter-process communication techniques.  UDP wouldn't
be my first choice when it's all on one machine.  Shared memory is nice
and fast but you have to actually write code.  A named pipe is simple
to use and not slow either, and you can dump the output of any emitter
program into the pipe without having to re-design the emitter to send
via some special method like shared memory or broadcast.  But probably
only one process could open the pipe at a time.

> objects requires that I somehow map what needs to be displayed in a
> deterministic manner to what the theme specifies using the names
> recognizable by the theme.
> 
> 2) A few people have mentioned displaying images. Static images are
> easy
> because you can just specify the 'background' PNG in the theme to
> contain
> whatever image you want -- this will be displayed as the notification
> background and it independent of what I've done. However, I don't
> know of a
> way to handle dynamic images. Images can be too large send via UDP

Yep.  I was thinking that the daemon which listens for caller ID
packets and translates them to OSD-messages could query a web server
for an image.  (You could configure the URL that it uses... something
like http://server/get-caller-image.cgi?name={name}&number={number},
and it would substitute for {variables} from the data in the CID
packet.)  Maybe it could cache them locally too FWIW.  And it's
possible to base-64 encode images and embed them in XML, although that
has some overhead obviously.  (The idea is to have a face to go with
the name and number right?)  They could even be animated MNGs if we
want to get all fancy.  Might as well have a custom sound too (again,
gotten from a web server).  I could have the Audrey version of the CID
client display the image and play the sound some day.  I'd thought of
that already....

Then again maybe we ought to make sure everything's compliant with the
uPNP standard (or JXTA or Jabber or something).  Somebody's probably
already doing caller ID on Windows that way.  But when I read the spec,
I got the impression they didn't use UDP, and therefore didn't like it
very much.  TCP for everything... sigh...

> Displaying the key/value fields of the above command line arguments
> would
> seem to take away a lot of flexibility and result in a crude looking
> interface. I'm not sure how it would tie in with the OSD theme
> either.

Well the code would have to set the capitalization of the field names
of course, however you like it (all-caps, first-only, all-lowercase)

>  This looks more doable. However, what performs the 'magic' of
> converting
> the command line to something that maps to the OSD names. One persons
> theme
> might specify the Caller Name to be displayed in a container in the
> top left
> corner and the Caller Number to be displayed in a container in the
> top right
> corner. A different persons theme might specify a container to
> contain both
> Caller Name and Number. 

Well then you'd probably have to have different themes for different
classes of notifications other than Caller ID.  It's probably a good
idea anyway, because some notifications are more urgent than others.

>   A few people have mentioned XSLT to do the mapping. How would this
> work?

You need an XSLT engine, which takes in a source XML file, and another
XML file that defines how to do the transformation, and outputs a new,
transformed XML file.  But I suspect we can find simpler ways to do
this; XSLT is more powerful (and more painful) than we probably need.

>   Next, a 'mythudpnotify' receiver would be needed which receives
> broadcast
> UDP/XML events (such as a callerid event) and maps them to command
> line
> arguments of 'mythosd'. Any ideas on how this would occur?

That's one that I could write, but it sounds like we're leaning towards
XML rather than command-line args.  Using some kind of template into
which I substitute the fields taken from the CID packet would make
sense; kindof like you did except this would get done on the CID
machine rather than on the server.

>   Lastly, my current cidbcast would generate a callerid event instead
> of
> something myth specific. We could look at merging some of
> Shawns/mine.

Yep.


=====
. _______  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


More information about the mythtv-dev mailing list