[mythtv] [PATCH] revised/added protocol extension patch -- ignorelast one

[David Shay]

----- Original Message ----- 
From: "Brad Templeton" <brad+mydev at templetons.com>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Sunday, May 01, 2005 2:32 PM
Subject: Re: [mythtv] [PATCH] revised/added protocol extension patch -- 
ignorelast one


> On Sun, May 01, 2005 at 01:45:01PM -0400, Noone wrote:
> > It is a step in the right direction imho.  Since the end result would
also be the backend caches much of the commonly requested data (recorded
list, guide data, ICONS, etc.), the hit shouldn't be that bad.
>
> I don't know about the insides of mysql, but surely it caches data of
> common queries, no?  And far better than an intermediate backend could do
> because the intermediate backend is not aware of possible writes to the
> data by other sources (including in some cases itself.)

I really have no interest in any potential performance improvements here.
So far we are talking about very small queries and result sets.  When we get
to guide data the result sets could potentially be larger, but even there I
would expect to do relatively small queries for limited ranges of channels
and date/times.

>
> I remain curious on the strong goal here.  I mean yes, there can always
> be value in extra levels of abstraction, but your talking raw SQL
> and getting back only slightly modified query results so little
abstraction
> is being added.
>
> Is it that sql query libraries are not available for some clients?  Is it
> that they are too expensive?  Is it that they are too hard to code for?
>

Actually, I care more about the specific queries than the generic one.  If
the objection is primarily to the generic one, then I'll remove it if I can
get the other ones in.  I believe the abstraction layers argument is pretty
valid for some of these, and would be even more so for scheduling a new
program.

Some of these clients are very small with very limited RAM.  Also, so far
both mythroku and mvpmc use different processor architectures, so each would
require a separate/unique libmysqlclient.  It's not always easy to
get/compile these, since mysql isn't always directly or easily supported on
these architectures without going through tons of hoops, and the results are
not always predictable.  If we can get the common library (libcmyth) to
provide for the typical frontend functions, this issue can be avoided.

I don't believe that these functions are really adding much overhead overall
into the myth code base, since they just make use of existing functions -- 
they don't even call the SQL themselves, but rely on existing ProframInfo
functions.

Overall, I just want to provide some additional options for low-cost
frontends.  You can get a relatively good quality standard-def
pseudo-front-end for about $79 or so with the Hauppauge MediaMVP.  You can
turn a Roku into a great quality HDTV front-end for about $299.  Both are
completely silent and have a standard A/V profile for fitting in with
existing equipment.  The Roku is especially appealing since it also has a
built-in uPNP client.  Once I have some more time, I am planning on
extending mfd with a uPNP server. [Yes, I know there is an existing project
at cybergarage.org that does some of this, but it doesn't provide everything
I am looking for with respect to sharing mythtv, mythvideo, and mythmusic
content].