[mythtv] new protocol

[David Whyte]

I think the major issue is having two copies of the queries.  All
clients will need to be updated if a performance enhancement or table
change were made.

IMO it is much easier to ask for the data, and know just the format of
the data that is being returned.

Whytey


On Thu, 24 Feb 2005 19:58:41 -0800, Brad Templeton
<brad+mydev at templetons.com> wrote:
> On Thu, Feb 24, 2005 at 09:01:36PM -0500, Anduin Withers wrote:
> > > However, is there any interest out there in writing a new protocol that is
> > > able to give a remote frontend absolutely everything it needs to deal with
> > > myth?
> >
> > I know it is heresy but I'd like the same thing, if people want/need direct
> > access to the DB let them do it, it doesn't preclude a good, DB free
> > protocol (I personally would like a protocol that would let me even fetch
> > the guide data, modify settings, etc).
> 
> Well, myth would probably need 2 protocols in any event because the RPC
> protocols like SOAP etc. don't really do streaming per se, do they?
> 
> But tell us why your above proposal makes sense?  I mean SQL is not
> that heavyweight of a protocol (probably lighter than SOAP) and there's
> a lot of effort to make SQL client libraries for lots of platforms, so
> what is the benefit of having to have a protocol to ask the backend to
> do queries for you and reformat the results to send back to you if you
> can do it to the DB easily enough?  Is it that you can't do it to the DB
> on some platforms, but you could do SOAP or CORBA or other queries?
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
> 
> 


-- 
GMAIL is 'da bomb baby....YEAH

I have GMail invites, if you want one, email me direct.