NNTP over HTTP gateway.txt

Request for status information
    * ?action=about&...
    * CAPABILITIES
    * DATE
    * ...
  
  Retrieve some basic information about the service. For instance,
  which authentication method the service would like to use, or if
  some optional protocol features are implemented. Can also be used
  to support the DATE command by looking at the Date header. If
  posting is supported, this might carry information on whether
  features like BBCODE or Markdown or whatever are supported? If
  HTML posting is welcome? Or should that be per-group meta data?

Request for article contents
    * ?action=article&group=...&msgid=...
    * ?action=article&group=...&number=...
    * ARTICLE:
    * HEAD:
    * BODY:
    * STAT:

  Simply retrieves the indicated article either by Message-id or
  by article number. The group argument needs to be optional to
  support the case where the currently selected group is "invalid".
  HEAD, BODY, and STAT are just ARTICLE with less information.

Posting articles
    * ?action=post&...
    * POST:

  This should be pretty obvious. It could be considered whether
  this would take a raw MIME message or something that is easier
  to parse. Then again, posting is an optional and not terribly
  interesting feature at this point.

Enumerating groups
    * ?action=listgroups&...
    * NEWGROUPS:
    * LIST NEWSGROUPS:
    * LIST ACTIVE:

  This should probably just list all groups along with taglines,
  creation time if available, display names better than the NNTP-
  mandated format, and whatever else might make sense. The data
  can then be filtered to implement the various commands.

Enumerating articles
    * ?action=listarticles&groups=...&from=...&to=...&max=...
    * GROUP:
    * NEWNEWS: 
    * LISTGROUP:
    * NEXT:
    * LAST:

  This is the most problematic aspect of the whole idea, it is
  probably not easy in many cases to generate article numbers
  in the required fashion, particularily generating one for the
  first article may be hard if on the one hand you want to
  support retrieving even very old data if users want that, but
  getting to them might require a lot of effort. The protocol
  however insists giving the number even when the user does not
  want such old data, which probably leaves most services with
  the option to pick in number around 1 billion when the user
  asks for the "latest" articles for the first time. I am not
  sure yet whether and how to support multiple groups in one
  request, it gets a bit messy with article numbers and such.

  I am thinking that this would fetch "long" lists of article
  numbers, message ids, and other data at once and then derive
  the data for the individual commands from it. One thing I'll
  need to investigate is whether and how long-running actions
  can be handled here, it might take a minute to index data if
  a new group is seen for the first time or if nobody asked to
  synchronise data for a group for some weeks.