[mythtv] Record now?

[James Sleeman]

Bruce Markey wrote:

> James Sleeman wrote:
>
>> 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. 

True yes, not in all cases.

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

Obviously a (capable) database is required, and it is not an efficient 
use of developer time to reinvent the database, hence my suggestion of a 
lightweight embeddable database as a default engine (eg SQLite as I 
noted, which I think would be quite capable of handling the data 
requirements of mythtv, easily so) which gives you most of the benefits 
of a big engine such as mySQL without the setup & administration & overhead.

> the choice of mySQL was because it is ubiquitous.

Only if you have need for an RDBMS, if you don't then why should myth 
require it be installed when a lightweight embedded solution may be 
better suited to the application.

>> 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

Abstraction --  PostGres != mySQL != MSSQL != jetSQL etc, there are 
minor (and major) differences between these systems, by abstracting the 
DBMS connectivity to an extendable class it means that the proliferation 
of SQL and exceptions to SQL is limited to within that one class.

Simplification -- The less connections between frontend and backend, the 
simpler it becomes, for developers and users alike.  Ask yourself this, 
if you were the frontend, why should you care about the database driving 
all this, all you care about is what the backend tells you and what you 
tell the backend.  

With multiple developers it becomes even more so, if a developer working 
on the backend comes up with some new stuff  in the database engine 
(whatever that shall be) he shouldn't have to describe all these low 
level details to front end developers wanting to use this information, 
they should just say to the backend - "Hey, I want this information" and 
the backend gives it to them after doing "things" to the database, if 
another developer comes along developing something else, they can also 
just ask the backend for the information, less duplication of code, less 
places for things to go wrong.

> The frontend can make the query (from the same library code) and cut
> out the middleman.

Yep, and I can go and milk a cow if I like and I cut out the milker, 
truck driver, milk processing company, bottlers, and milk man - but I'd 
much rather not know how my milk gets to me, all I care is I give money 
to the milk man and he gives me milk all nice and ready to drink.  If 
I'm, the front end, I could find out what database we're using, open a 
connection to it, select from the right table, being careful to make the 
select correct, etc etc but I'd much rather not know the gory details, 
I'd prefer to just ask a backend - backend.getListOfShows(channel, from, 
to), or backend.deleteThisShow(showID) or backend.recordThisShow(showID) 
or backend.streamMeShow(showID)  you get the idea.

---
James Sleeman