In said:
One thing I would really like to do (alas, have no business model for it)
is to marry NNTP with podcasts and RSS.
So called "flooding protocol" is something I find quite amusing, and aside from
NNTP (AFAIK) isn't widely used anymore. Seems like it's almost always a central
master -> slave model, (mirrors, etc.. CPAN for example)
Having "NPTP" (Net Podcast Transfer Protocol? NRTP Net RSS Transfer Protocol?) [...]
Unlike NNTP, the enclosures and other RSS fields would have to be planned for
(possibly with delayed transfer/referral of enclosures)
I think regular NNTP would work just fine for that. Just use appropriate
content-types (application/rss+xml, audio/*, video/* or whatever). You
may want a subscription mechanism in the protocol (NNTP for normal
newsgroup could use one, too, but subscribing whole hierarchies is
"traditional" and so far nobody has had enough incentive to push for a
more fine-grained approach).
The bit I can't work out is how you'd associate other types of information.
The title, description and other elements of the RSS entry, keeping the
enclosures distinct, supporting multiple enclosures pr. item and ensuring
that the items are stuck to the correct feed. Unless each feed were
it's own newsgroup, this doesn't seem viable. (threading, maybe.. but followups
might be better used as discussion areas and/or corrections)
I'm probably missing something because I know little about podcasts, but
AFAIK they consist basically of
* individual media files
* RSS (or Atom, or whatever) files which refer to the media files and
add a bit of information about them.
The RSS file normally is at a fixed URL, and clients poll the URL to see
if the file has changed, and either notify the user or automatically
download the new media files so that the user can listen to them resp.
view them.
So as a first step you can set up a set of newgroups with categories.
Then instead of (or in addition to) posting your RSS file on a web site,
you post it in the apropriate newsgroup(s). Clients subscribed to at
least one of the newsgroups will retrieve the RSS and can continue to
act just the same as if they had retrieved it vie HTTP. (The user might
want to specify additional filters, for example automatically download
only files by author X or with subject Y).
The harder part is to distribute the media files themselves over NNTP:
You can just post them to the same newsgroups, but that means that every
file is flooded to every server subscribed to a newsgroup. Well, let's
just say there's a reason why most newsserver operators don't carry
binary groups
.
That's where the "more finegrained" subscription model I was talking
about comes in. Traditionally, feeds in NNTP are configured
"out-of-band": If I want a feed for some newsgroup, I send mail to my
neighbour news admins, and tell them I want to get a feed for that
newsgroup. Of course that's quite a bit of work, so it's almost never
done for individual groups, but only for hierarchies (so I'll say "I
want a feed for comp.*, at.* and de.* but without de.alt.dateien.*" or
something like that). If NNTP offered a way to configure feeds, that
could be done automatically, so turning on and off feeds for individual
groups would become feasible.
So you could have one newsgroup per channel, and each server only
requests a feed for that channel when there are users actually reading
items from it (Incidentally, that gets rid of the problem that neither
nor nntp: URIs allow specifying both a message id and a newsgroup)
So, if I wanted to make podcasts, I'd start by creating a new newsgroup
for my channel on my news server (there may need to be some global
naming scheme to avoid collisions, for example by using the reversed
domain name as prefix: "podcasts.channels.at.hjp") and post my first
opus there:
From: <
[email protected]>
Newsgroups: podcasts.channels.at.hjp
Subject: Writing a newsserver in perl
Content-Type: video/mpeg
Message-Id: <
[email protected]>
Then I'll post an RSS file to the appropriate categories newsgroups:
From: <
[email protected]>
Newsgroups: podcasts.categories.programming.perl,podcasts.categories.comm.usenet,podcasts.channels.at.hjp
Subject: Writing an nntp server in perl
Content-Type: application/rss+xml
Message-Id: <
[email protected]>
<?xml version="1.0"?>
<rss version="2.0">
<channel>
<title> HJP's rants </title>
<link> news://news.hjp.at/podcasts.channels.at.hjp </link>
...
<item>
<title> Writing a newsserver in perl </title>
<link> </link>
<description>
A very boring presentation about the nntp server I
wrote in perl.
</description>
<guid> (e-mail address removed) </guid>
<enclosure href="type="video/mpeg" length="12345678" />
</item>
</channel>
</rss>
<!-- or something like that - please ignore any errors in the RSS -->
Done.
The RSS will be flooded out to all servers which carry either
podcasts.categories.programming.perl or podcasts.categories.comm.usenet.
The video will currently stay on my own NNTP server, because no other
carries podcasts.channels.at.hjp yet.
A client will get the RSS file, and if the user requests my
presentation, it will first try to enter the group
podcasts.channels.at.hjp and request the article <
[email protected]> at
the local server(s), and if that fails, from news.hjp.at.
The server will notice a request for a non-existing newsgroup
podcasts.channels.at.hjp and request a feed from its peers. If none has
it, it may parse the RSS files to find that this newsgroup is available
from news.hjp.at and request it there (it is a matter of policy if a
server should autonomously establish new peer relationships).
One may not want to spool all the enclosures, but rather defer them until
someone requests them. Just flood the metadata, rather the way leafnode/suck
type news servers work, the .overview should contain as much of the RSS
data as possible.
See above for an idea on how to flood metadata and enclosure via
different paths. The .overview could contain the content type and maybe
other data, but I don't think that's necessary - the RSS files are small
enough compared to the media files.
Would be "nice" if you could go RSS -> NRTP -> RSS, loosing as little data as
possible AND provide "discussion boards" on NNTP instead of those crummy
web-based things.
Regular postings in plain text can be intermixed between RSS and media
postings. (Hey, you can even have a discussion thread consisting of
audio or video postings
.
NNTP isn't 8-bit clean and doesn't really provide a way to xfer enclosures.
NNTP has been in practice 8-bit clean (although not binary-clean) since
the early 1990's. Even before, binaries were distributed just fine using
uuencoding. Today base64 and yenc exist as alternatives. Distributing
binaries over NNTP is really not a problem - people have been doing it
since the beginning of Usenet.
hp