[mythtv] MythSOAP Expressions Of Interest

[Adam Jenkins]

>>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