[mythtv] MythSOAP Expressions Of Interest

Mon Feb 21 18:39:10 UTC 2005

How about just changing channels?

"Got myth running across the room and don't want to track down the
remote? use this!"

Mike
On Tue, 22 Feb 2005 05:19:39 +1100, Adam Jenkins <mail at adamjenkins.net> wrote:
> >>Whether it's  a SOAP, DBus, or MythTV Protocol
> 
> I'm still at a loss why it has to be one or the other to tell you the
> truth.  If you have a good OO system with, say, a bunch of command
> objects using a marshaller/unmarshaller system.  Write the
> marshaller/unmarshaller with a standard interface and make it an
> abstract boundary (AbstractFactory).  Let the user decide which protocol
> they want to run.  In this case, the only thing that needs to change to
> support different protocols is the marshaller/unmarshaller.  Then, when
> <insert fantastic new protocol here> comes along, you can just write a
> new marshaller/unmarshaller and plug it in when required.
> 
> I realise that SOAP gets a lot of technical resistence in many cases,
> and that resistence is rightly deserved for all the reasons pointed out
> previously on this thread.  However, I think you'll agree, for client
> language/platform independence, speed of development, low knowledge
> barriers to entry and general cross industry acceptance it's quite
> difficult to find a better substitute at the moment.  So, while I
> understand your concerns in wishing to implement different protocols,
> I'm sure you'll agree that being locked out of something like SOAP would
> also lock us out of a lot of good functionality.
> 
> As I discussed in the first paragraph, the actual protocol itself, in a
> good OO system is a bit of a moot point.  Because of this, I would like
> suggest starting with SOAP for the proof of concept because of the
> reasons outlined in para 2, and following the design notes in para 1.
> That way you'll end up with a common set of command objects that can be
> bound regardless of protocol, and a set of common interfaces for the
> protocol handlers (marshaller/unmarshaller).
> 
> Can anyone suggest a simple use case for a proof of concept?
> 
> Cheers
> Adam
> 
> On Mon, 2005-02-21 at 10:09 -0500, Michael Luich wrote:
> > 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.
> >
> > Mike Luich
> >
> > 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.
> > >
> > > -Tako
> > > _______________________________________________
> > > mythtv-dev mailing list
> > > mythtv-dev at mythtv.org
> > > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> > >
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
> 
>