[mythtv] Record now?

[Pat Pflaum]

Uhhhh....what?    I don't *thinik* there's a question of moving the data 
out of mysql or *A* database anyway , I think the debate has been...

 a)  should the backend provide an interface to the database
or
 b) should the frontend connect to the database directly

Security wise, a makes more sense, but how secure do you want your 
recordings of M*A*S*H to be???

In most situations all connections would be behind  a firewall 
hopefully, and connecting to the db directly, and even through an api 
would be less costly than asking for the info through the backend.

Personally, I don't care who knows that I record junkyard wars, but 
ymmv. ;-)



Pat




Joseph Stump wrote:

> 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."
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at snowman.net
> http://www.snowman.net/mailman/listinfo/mythtv-dev