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

[Geoff O'Callaghan]

Isaac Richards wrote:
> On Sunday 01 May 2005 03:32 pm, Brad Templeton wrote:
> 
>>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.)
> 
> 
> Exactly.  mysql does a pretty good job of caching things properly, so repeated 
> queries are damn quick - especially for simple stuff from the settings table.  
> Doesn't make sense to me to recreate all that in the backend.  Might as well 
> just write your own DB at that point.
> 
> 
>>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?
> 
> 
> My questions as well, every time this is brought up.  libmysqlclient's just a 
> cross-compile away for almost any platform.  It's tiny, too - if a platform's 
> that starved for RAM, it's not going to be capable of displaying much of a 
> UI, either.
>

Sorry, wasn't much I could snip there as it's all relevant.  I'm a noob 
here so apologies :-)  I think both points of view are valid.  MySQL 
obviously does aggressively caching, but I also think myth could benefit 
from caching of application objects.

ie.  The f/e talks to the b/e in terms of 'application objects' rather 
than SQL objects.  These objects are 'cached' using an application 
caching layer which in turn sits on top of the DB layer.  The advantages 
is that the f/e and b/e can use a simple application cache using 
something like 'object invalidation' (eg someone has modified the tables 
directly which means the b/e invalidates the object which in turn allows 
the f/e to tell that things have changed with a small exchange of data) 
to keep in sync and the b/e can worry about the SQL objects and allows 
simpler integration of additional DB layers such as Berkeley DB or 
postgresql etc.

That probably didn't make a great deal of sense ;-) but I can try harder 
if required ...

Note: I've only just started looking at the mythtv code so I might be 
talking out my butt ....


-goc-