[mythtv] Record now?

[Bruce Markey]

James Sleeman wrote:
> Isaac Richards wrote:
> 
>>On Wednesday 15 January 2003 10:48 am, Stephan Wentz wrote:
>>  
>>
>>>that reminds me of one of my questions that hasn't been answered yet, will
>>>future versions of mythtv let the backend do all the sql-query-stuff? right
>>>now the frontend does it, and i don't think this is a good idea, since the
>>>backend should provide all the data that the frontend uses...
>>>    
>>>
>>
>>I disagree.  The backend doesn't need to provide _all_ the data, when much of 
>>it's just as easily gotten by hitting the sql server remotely.  It's not like 
>>the client libraries are huge or anything.
>>
> I think that Stephan has a point.  I find applications that require 
> mySQL to be installed and create database/tables etc are a pain - namely 
> because it's generally not necessary for the software to have such a 
> hefty (even if mySQL isn't exactly hefty) requirement, it adds to the 
> complexity for the system needlessly in most instances.

But not all instances, agreed? In this case, there are 1000's
shows with multiple fields of information, lists of recordings,
lists of titles to search for to be recorded, etc. Without a
database, the data would need to be stored in flat files and
you'd need to parse, error check, lock while writing... Oh,
write a new database. That would defiantly be a pain and
add complexity.


> ... I think that it 
> should be considered to have myth use something like SQLite 
> (http://freshmeat.net/projects/sqlite/?topic_id=67) by default (so that 
> no database engine is required for Joe Public) but keeping the option of 
> developing an interface to mySQL/postgreSQL/mSQL/MSSQL/Oracle/whatever 
> in the future - the best way to do this IMHO would be to have the 
> backend do the communicating with the database (through an interface 
> module perhaps) and the front end communicate with the backend for the 
> information it requires - this way the proliferation of SQL is reduced 
> to preferably one easy to maintain class, lets say mythDBManager which 
> is extended by specific implementations - mySQLDBManager, 
> postgresDBManager, sqliteDBManager etc, SQL is never given to the 
> class's objects, only method invocations to perform certain actions 
> (dbmanager.getShows(), dbmanager.deleteShows(), etc etc).

The database connection information is in libraries that
are linked in both the client and server so there is no
duplication of code. Even though the method names are not
exactly as you describe, it should be fairly simple to
modify the code to connect to other databases. I assume
the choice of mySQL was because it is ubiquitous.

> I havn't seen the CVS code yet (waiting for the 0.8 release really) so I 
> don't know how the frontend-backend split works in it's entirity, but I 
> believe that it uses a network filesystem for getting hold of the shows, 
> if not then ignore me totally while I talk from my ass, but if so I 
> think that requirement should be removed too, the frontend should ask 
> the backend to stream it a show rather that relying on the user to 
> perform _another_ administrative task in getting a network file system 
> up and running properly.

The A/V data is passed from the server to the client. There
is no requirement for file sharing.

> To put it simply, I think the frontend should only have to know how to 
> contact the backend, and that's all - everything it needs (video, 
> program listings etc) it asks the backend to provide to it.

To what end? What problem are we trying to solve? The
model should be one or more frontends connecting to one
or more backends. Tying a frontend to a specific backend
is counterproductive. As for db queries, realize that the
backend would need to connect to the database and send
the query then pass the result to the frontend. The frontend
can make the query (from the same library code) and cut
out the middleman.

--  bjm