[mythtv] MythSOAP Expressions Of Interest
ravenhair at gmail.com
Mon Feb 21 15:09:18 UTC 2005
I know for myself I don't care what method is used so long as it is
accessible and there is at least some basic documentation. There's
this great backend running on my box and I have yet to figure out how
to access it directly. Whether it's a SOAP, DBus, or MythTV Protocol
interface makes less of a matter to me than info on how to access it.
That being said I'd be more than willing to help with docs and
external access methods.
On Mon, 21 Feb 2005 12:18:13 +0100, Tako Schotanus
<quintesse at palacio-cristal.com> wrote:
> Tako Schotanus wrote:
> > Isaac Richards wrote:
> >> On Sunday 20 February 2005 06:52 pm, Kevin Kuphal wrote:
> >>> bill peck wrote:
> >>>> While I do think SOAP would be handy I would settle for program guide
> >>>> data being available over the current Myth Protocol instead of having
> >>>> to do SQL calls.
> >>> This type of increased independence of the frontend was something I had
> >>> mentioned to Isaac as a point of interest to me. Not specifically for
> >>> SOAP, but having more functions in the protocol would lend itself to
> >>> improving such an effort just as it could have a positive effect on the
> >>> MediaMVP work, etc. He wasn't against it but noted that currently only
> >>> the functions required to be done on the backend are done there. Not
> >>> sure when I might have time to visit this, but it is something I'd like
> >>> to work on as well.
> >> Right - this would move to _requiring_ the backend to be running for
> >> everything. It's not now, and I don't know if I'm happy with that
> >> additional requirement.
> > You don't need the backend running for just about everything right
> > now? There might be some tools that don't need a connection to the
> > backend but as far as I see it they could still continue to do so,
> > access to the database server would not be prevented. But it would
> > give other frontend applications a way to get at all the possible
> > information using a single point-of-entry.
> >> Additionally, my concern is that SOAP (like anything using XML) adds
> >> a lot of size + parsing complexity to what needs to be a lightweight
> >> system if it's going to be used for all message passing between
> >> processes.
> > I tend to agree with you here. I myself have been looking for some
> > time now at the DBus project
> > (http://freedesktop.org/wiki/Software_2fdbus) which is a very
> > light-weight IPC message bus. The problem so far has been the lack of
> > finished QT bindings.
> NB: In another part of this thread I saw that you would only consider
> another protocol if it could replace the current protocol. I hadn't
> really looked at DBus that way because I was just looking for a way to
> get at all the information that is available in the backend and also a
> way to for external script to perform (controlled/checked) actions in
> myth. (eg. I could write a shell script that somehow deletes a recorded
> program from both database and filesystem but that wouldn't update the
> display on any running frontends. It would be nice if you could just ask
> the backend to do it for you. Of course you could implement the myth
> protocol in perl or whatever but that's why I was looking at DBus: most
> bindings already exist).
> But DBus uses a light-weight binary protocol so theoretically it should
> be possible to replace the myth protocol. Don't know if there are any
> downsides or if the upsides are worth the trouble though. Still trying
> to find time to take a look at the Qt bindings and see if there's
> anything I can do to help them along.
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
More information about the mythtv-dev