Subject: Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

From: Eric Wong <[email-masked]>
Date: Wed, 24 Aug 2016 19:27:25 +0000

Jeff King <[email-masked]> wrote:
> On Wed, Aug 24, 2016 at 06:49:38PM +0000, Eric Wong wrote:
> > > > Given that public-inbox provides an NNTP interface, couldn't the ARTICLE
> > > > <message-id> NNTP command be used to easily retrieve the messages in a
> > > > given patch series (at least compared to POP or IMAP).  Perhaps
> > > > git-send-email could be modified to include the message-id value of each
> > > > patch in the series that it sends to the mailing list and include it in
> > > > the cover letter.
> > 
> > I think that makes sense; perhaps an X-Git-Followups: header
> > from send-email which lists the child Message-IDs the same way
> > References: does for ancestors.  (perhaps there's already a
> > standardized header for listing children)
> 
> I think that's harder to adapt to some workflows, since it implies
> generating all of the message-ids ahead of time (whereas if you are
> feeding the messages into an existing MUA, it may generate them on the
> fly as it sends).

Yeah, it would be limited to git send-email users, only :<

> > I thought about allowing a giant MIME message with all the
> > patches attached, too but that won't work for a large patch
> > series due to size limits along various SMTP hops.
> > Compression might make spam filters unhappy, too.
> 
> This was a problem faced by binary groups on Usenet, which had to split
> large files across many messages.
> 
> It has been a long time since I've dealt with those, but I think the
> state of the art involved using "1/20", "2/20", etc in the subjects to
> piece together the original. There may also have been header or body
> content that included a unique id, so you always knew which messages
> were part of a set.
> 
> They also used things like forward error correction to handle dropped
> messages, but I don't think we need to go that far.
> 
> So parsing the "PATCH 1/20" headers sounds hacky, but I think it has
> worked for years in other communities.

nzb (an XML format) seems to be the thing for Usenet binaries,
nowadays.  Maybe it's workable for git, maybe it's overkill or
not worth it for the two (non-.onion) NNTP servers we have.

nzb seems widely supported enough (on a Debian jessie system):

$ apt-cache search nzb
sabnzbdplus - web-based binary newsgrabber with nzb support
sabnzbdplus-theme-classic - classic interface templates for the SABnzbd+ binary newsgrabber
sabnzbdplus-theme-iphone - transitional package for migration to sabnzbdplus-theme-mobile
sabnzbdplus-theme-mobile - mobile interface templates for the SABnzbd+ binary newsgrabber
sabnzbdplus-theme-plush - plush interface templates for the SABnzbd+ binary newsgrabber
sabnzbdplus-theme-smpl - smpl interface templates for the SABnzbd+ binary newsgrabber
libnzb-dev - An nzb based Usenet binary grabber (development files)
libnzb0c2a - An nzb based Usenet binary grabber (runtime library)
lottanzb - simple and automated Usenet downloader for Newzbin (NZB) files
nzb - Usenet binary grabber
nzbget - command-line based binary newsgrabber for nzb files
python-pynzb - unified API for parsing NZB files from NNTP (Usenet) servers
spotweb - web interface to search and filter Usenet spots