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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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 > > > [email protected] > > > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev > > > > > _______________________________________________ > > mythtv-dev mailing list > > [email protected] > > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev > > > _______________________________________________ > mythtv-dev mailing list > [email protected] > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev > > >
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
