[mythtv] Record now?

[Joseph Stump]

New to the list, but I thought I should chime in. MySQL is a well known 
DB, which allows, if nothing else, widespread addon/module development. 
For instance, once I have my MythTV box up and running I plan on 
writing a WAP module in PHP/MySQL because I'm sure I can figure out the 
table structure, etc.

IMO MySQL is rather simple to set up - more so than most. Yes it would 
be easier to embed it into the backend, but you would end up hindering 
innovation in the end because the standard/files wouldn't be as open 
and widely understood.

--Joe


On Thursday, January 16, 2003, at 12:29 AM, James Sleeman wrote:

> 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
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at snowman.net
> http://www.snowman.net/mailman/listinfo/mythtv-dev
>
>
>
--
Joe Stump - joe at joestump.net
http://www.jerum.com
"Software never has bugs. It just develops random features."