[mythtv] Record now?
joe at joestump.net
Thu Jan 16 00:46:09 EST 2003
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.
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
Joe Stump - joe at joestump.net
"Software never has bugs. It just develops random features."
More information about the mythtv-dev