[mythtv] How are backend/frontend/modules separated?

[Andy Davidoff]

Imposing these limitations may result in improvements in Myth, but it makes
it harder for those of us who are trying to write applets on the side.

Myth's database dependency may not be as rigid as the proprietary client
protocol, but it's much easier to develop against.  Extending the protocol
beyond audio/video streaming seems to force unnecessary complexity onto
clients that won't actually be playing media and really just want access
to the metadata.

For example, client requests (eg. delete-program) could be passed through
a stack in the database, which the backend could deplete at leisure.  This
would let clients (eg. MythWeb) work more simply, without backend access.
The backend already polls the database every second, so this model is in
effect already being used for more specific message passing.

To answer your original question, I don't see any issue with using a queue
as above to ensure that a backend is the only process making updates to the
database.  This would give us the best of both worlds.


#if Thor Johnson /* Mar 27, 01:30 */
> Ok... a dev question that will probably prompt me to rewrite a few things
> (such as changing descriptions of recorded programs):
>
> What resources are which programs supposed to access? (e.g. should
> mythfrontend *not touch* the database)
>
> It seems almost logical to have that restriction (that way, you don't
> need to have the mysql net permissions installed unless you're running
> mythweb), but it requires implementing messages to do things that touch
> the database (e.g. my edit patch boils down to an update statement that
> is buried in the container for recorded programs used in playbackbox.  If
> mythfrontend shouldn't touch the database, I'll need to add appropriate
> messages...).
#endif /* thormj at ieee.org */