Robert Johnston wrote:
On 30/10/05, Michael T. Dean <[EMAIL PROTECTED]> wrote:
Robert Johnston wrote:
Incorrect. You can pass --disable-frontend and/or --disable-backend if
you want to make a FE-Only or BE-Only machine.
Yeah, if you don't want it to build. Those are porting only
options--they are /not/ valid options on Linux. See
http://svn.mythtv.org/trac/browser/trunk/mythtv/configure?rev=7650 lines
2740 and 2747--and especially lines 2741 and 2748.
These USED to be valid options to build a front-end only system (As it
seems very wasteful to have to build the whole of the backend, just to
never use it, especially on something like an XBOX-frontend, which
will NEVER be able to offer backend functionality, and building the
binaries (As well as keeping them) will only waste CPU time and HDD
space).
These were changed in Rev. 7577 to add the warnings mentioned above,
Right, but the warnings were added because of the sheer number of
posts/tickets where people reported that they couldn't build their
"lightweight" MythTV system using "--disable-backend" or
"--disable-frontend".
Here's the commit message where the options were first added. Note the
"so it should be considered as something useful only for porting the
backend," and "The basic aim here" parts.
http://www.gossamer-threads.com/lists/mythtv/commits/136628#136628
and TBH I think changing this breaks the whole "Client-Server"
functionality that Myth is supposed to be promoting, with independant
multiple frontends and multiple backends. It used to be that a backend
machine didn't require the behemoth that is X to compile, or run, but
with these dependancies, it makes what should be a small(er) program
with only the dependancies on what it needs become a huge thing that's
not efficient at all.
AIUI, Isaac has (rightly, IMHO) taken the stance that a "few" extra
megabytes of installed applications on a system that processes
multi-gigabyte files does not provide sufficient cause to justify the
work entailed in separating the two such that each is completely
independent of the other. If you really want that lightweight frontend
or backend, though, feel free to submit patches. ;)
As a matter of fact, the same applies to
mythplugins--you need the same version of mythplugins as the version of
mythtv.
That's also incorrect. MythPlugins have to be built against the same
version of libMyth, but you can take an old version of the plugins
source, as long as it's built against the same version of libMyth as
the MythFrontend you are wanting to load them from.
Unless there are changes that break compatibility. This includes
incompatible changes to the myth protocol version, the DB schema
version, the libraries used by the plugins (i.e.
http://svn.mythtv.org/trac/ticket/531 ), and ...
In thoery, each "Plugin" should handle it's own "DB Schema", as they
should be interchangeable. IOW, MythWeather should not be touching
MythVideo's DB entries, and MythTV should not be changing MythNews'
schema.
This would mean that you could mix-and-match between Plugins/MythTV
versions, with no compatibility issues.
Yes, but MythWeb is actually more of a completely independent frontend
than a "plugin," so it /requires/ knowlege of the DB schema. This is
actually why the current MythWeb can corrupt custom recording rules and
other features new to the DB schema--it hasn't yet been completely
updated for some of the changes.
And, in /all/ cases, doing so is *not* a "supported"
configuration--which was the point I was trying to make. Unless, of
course, you're volunteering to provide support for all possible version
combinations users may wish to try.
Now, I'm not going that far. But you *should* be able to compile a
backend-only system without anything breaking, as it's meant to work
independantly of any frontends that may be attached to it. Likewise
with the Frontend-Only compilation. If there is functionality that is
used in both the frontend and backend, it should be modularised so it
can be used in both independantly (Moved into libmyth, perhaps?).
Otherwise, there's not much point in having seperate front-end and
back-end programs, and the whole thing might just as well be one
massively-threaded monolithic program.
My £0.02 ($0.0355157USD)
IMHO, having the mythbackend on disk on my frontend or the mythfrontend
on disk on my backend is not a big deal, but being able to run
mythbackend without starting mythfrontend or vice-versa is critical.
As for breaking the client/server functionality, it's hard enough
getting people to understand what they do and don't need with just a
"mythtv" program that gets installed on all their Myth boxes--regardless
of whether they're dedicated backends or dedicated frontends or combined
frontend/backend boxes. I can only imagine how complex this would get
with mythfrontend, mythbackend, and libmyth--and people trying to use
varying versions of mythlib with
mythfrontend/mythbackend/mythplugins/whatever.
I'll admit it could be made a more elegant solution, but I'd rather have
new features like mythui or mfd than an opportunity to save 100MB
storage space (which is enough space for about 6 minutes of relatively
low-quality video ;). Even if it turned out to save 500MB, I don't see
the value in the savings.
Mike
_______________________________________________
mythtv-users mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
