[Openpvr-devel] Re: [OpenPVR] Re: [Xmltv-devel] XMLTV Query API

[James O. <jf...@fu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On November 30, 2001 08:58 am, Edward Avis wrote:
> >Excellent. I feel much better knowing that we're in agreement here, and
> >I think that any XMLTV-based program will generate more interest if
> >there are compatible APIs in multiple languages.
>
> Well at present XMLTV.pm is just an interface for Perl, obviously.  If
> there's serious interest in a similar API for other languages then I
> might rewrite most of it in C or C++ so it will be possible to interface
> to it easily.

The reason I like XMLRPC and SOAP so much is because you can make an API in 
one language and use it seamlessly in any other. You can even access one 
using only bash with telnet, cat, and wc. Check out the last section of this 
page:

http://developer.kde.org/documentation/kde2arch/xmlrpc.html

That said, I'm sure that if you made a simple document outlining the 
functions, then many compatible language interfaces will just show up. I'll 
be making a Python one anyway (not that I'm adverse to Perl, of course). I 
don't want OpenPVR to be tied to any language.

I'm thinking of doing both an xmltv.pm compatible interface through XMLRPC, 
possibly allowing a Meerkat-style section.


> I don't disagree that such a function is useful.  But I think that it
> should be written like this: (Perl syntax)
>
>     my @results;
>     foreach (@programmes) {
>         if (XMLTV->matches($_, show => 'Simpsons')
>          or XMLTV->matches($_, time => '17:00:00') {
>             push @results, $_;
>         }
>     }
>     return @results;
>
> In other words the matches() routine is the important one, it just tests
> an individual programme.  Finding a list of programmes is done in the
> stupidest possible way by going through all of them and testing each
> one.  Any more sophisticated technique (such as keeping the
> programmes in sorted order and doing a binary search, or maintaining a
> separate index of keywords) is not needed given the relatively small
> size of the data.

Aha! Now it makes perfect sense. It makes creating high-level functions 
easier. Sounds good to me.


> >Locally, yes, but remotely, it depends on the XMLRPC or SOAP
> >implementation.  It's also neat to be able to browse the API and
> >execute methods in a web browser.
>
> Er, okay, but it's still not something that belongs in XMLTV.  If you
> want to write a standard for doing introspection over XMLRPC or SOAP,
> fair enough.  And then the code you write might conform to that
> standard.  But I don't want things like system.listMethods() being
> defined as part of the XMLTV project.

Oh, I guess I should have pointed out my intentions at first. I was talking 
about an interface for OpenPVR/PyTV and I CC'ed you guys to see:

1) Am I on crack or what?
2) Are you guys planning anything that hasn't been implemented yet?


> (If it is only your code that implements this listMethods()
> functionality, then what is the point of it?  Anyone who knows that
> listMethods() is available will also know about the other routines you
> have documented.  An introspection system is useful only if you can get
> widespread use of it.  So good luck with that, but it's not related to
> television listings per se.)

Yeah, it's part of the XMLRPC spec, but is not implemented automatically in 
all of the libraries (including the one I use) so I have to do it myself, 
which is ridiculously easy to do anyway. Most scripting languages have great 
introspection abilities.


> >This is entirely for daemons, and would be a separate library. It would
> >be cool if Jabber could pop up a minute before your favourite show
> >comes on. The record event is only useful for a PVR (mp1e is a video
> >recorder).
>
> That description makes sense, although I still don't get the 'event' API
> you are defining above.

Ah, basically, I would be able to make an XMLRPC call that tells the daemon 
to do something like:

- - "when the recorder has finished recording a show, tell the GUI using this 
function"

- - "when the GUI says 'channel_up' call 'v4lctl setchannel next'" (yes, that 
command works as expected, on any TV card)

- - "at 5:00 PM start the recorder on channel 53"

Basically, you could define all functionality this way and even set/change it 
on the fly (via the GUI, for example). This is basically the same as Qt's 
signal/slot mechanism. It makes stuff really easy to write. The main 
difference here is that the senders and receivers are programs (or wrappers) 
instead of objects.

Yes, I'm using XMLRPC as an IPC mechanism, but that gives us the ability to 
distribute the load across multiple computers: you can watch stuff on another 
computer using streaming video. Try getting your Tivo to do *that*

Thanks,

- -- 
James Oakley
jf...@fu...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8DCYyKtn0F7+/lLMRAozGAKClEG0As2BogLnSUXL7Duri/pY30QCdEI2u
0SKKuPxchbK7GbXRJ6I1d1U=
=DacF
-----END PGP SIGNATURE-----