[mythtv-users] Mooting architecture for a DataDirect replacement

[ICMan]

I wasn't trying to convince people to use the existing DNS
infrastructure to propogate channel info, I was trying to convince
people to adopt it's distributed heirarchy of authority for data
management.  I guess better examples would be X.500 or LDAP.

I wanted to explore more the idea that data owners could put up program
listing data on their local "server", and finding it would be easy and
fast because the naming convention for owners would follow the DNS
model, or something similar.  This model also allows for "secondary"
repositories that are knowable by the inquirer, and are authoritative
because they get frequent full data dumps and differential data dumps
from the "primary" source.  The "name" of the station/server/service
bounds the data.  A server could be authoritative for more than one
domain (ie. station).  Perhaps the station names could be delegated by
the cable/feed company names (Rogers-Toronto, Star Choice-Chicago,
DirectTV-LosAngeles).

Listings information at each station could be stored not as large chunks
of aggregate data, but discrete chunks of smaller data elements, such as
individual episode descriptions, with their time and date information,
listing expiry, the level of confidence that this program will actually
play at the advertized time, and other properties that the stations want
to share about a particular TV episode.  Queries could ask for specific
information, or a complete dump of a station lineup, or something in
between, and the limits of the data dump could be configured by each
station.  Perhaps a metadata query to get the properties of the data
store (format, data dump limits, types or boundaries of the sets of
aggregate data available) would precede a larger data request.

I know Jay is flogging NNTP, but I just don't see how you get accurate
listings, a complete lineup, JIT listing changes, etc.  Would the
proposed solution put an NNTP server at every station, or would they use
existing commercial NNTP servers to propogate changes?  How do you
ensure everyone with a public NNTP relay carries the appropriate news
groups?  How do we tell people what news servers to point to?  Will NNTP
server administrators freak over the increased load on the servers that
contain MythTV Listings Newsgroups?  Perhaps I simpy don't know enough
about NNTP.  (I suppose that's pretty obvious).  But a query response
type mechanism initiated on demand by the user to a known repository
that's authoritative seems to me to be the solution which has the
promise to meet the service level requirements of the MythTV community,
and to scale beyond.

Just some thoughts.

ICMan

On Tue, 2007-26-06 at 10:03 -0400, Jay R. Ashworth wrote:

> On Tue, Jun 26, 2007 at 01:56:28PM +0100, Peter Bowyer wrote:
> > > hits will be differential data), DNS rules the Internet.  Literally.  With
> > > the properties of such a mechanism, why is it not being seriously considered
> > > on this list?
> > 
> > Because it was designed for lightweight, moderately static data. As
> > soon as you start loading DNS up with big records and the UDP queries
> > have to become TCP queries, the advantages of the mechanism fall away.
> 
> And additionally, because our being able to use DNS-as-it-is in the
> Internet at large for our purposes requires that it live up to
> assumptions which are safe about DNS in the abstract, but not as it is
> deployed.
> 
> Alternatively, we *can* make those same necessary assumptions about
> NNTP as it is provided commercially.  That's why I picked it.  :-)
> 
> > Just because DNS is good at caching sub-128-byte name resolution
> > queries, doesn't make it the right thing to use to move (relatively)
> > heavy listings data around.
> > 
> > Nail and hammer syndrome in evidence here.
> 
> Indeed.  Plus, since you're leveraging the Internet DNS infrastructure
> to do something it's not intended to do, you have little recourse when
> it breaks.
> 
> And NANOG would murder you in your sleep.  :-)
> 
> Cheers,
> -- jra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070626/7805de8d/attachment.htm