Re: [Monotone-devel] minor update

[graydon hoare]

Sebastien Pierre <address@hidden> writes:

> On 23 Apr 2003 14:52:49 -0400
> graydon hoare <address@hidden> wrote:
> 
> > http://www.venge.net/monotone/faq.html
> > http://www.venge.net/monotone/todo.html
> 
> BTW, what do you think about the idea of abstracting the patch
> import/export layer, so as to enable plug-ins for other protocols
> than NNTP (like email, or local, or web, or whatever) ?

as you see on the todo list, I intend to add some glue to work with
mailing lists. the patch transport format (ascii "packets") is
designed to be sendable over many media. it is 7 bit clean, 70-column
plain text, and can be concatenated or separated with line-oriented
operations.

currently monotone can *read* these packets from pretty much any data
source, through a pipe. the command is 'monotone read'. some minor
adjustments to 'read' mode will need to be made to fully integrate
with mailing lists:

- rejection of public / private key packets, by default. like with
  NNTP, you should not treat a mailing list posting as a secure
  out-of-band transmission of a key. it would be too easy to receive a
  bad key mixed in with a patch packet stream. 'monotone read'
  currently accepts key packets.

- queueing commits to send to mailing lists. this could either be a 
  copy-and-modify job on the nntp queueing code, or else an abstraction
  of the operation and associated tables to handle multiple protocols,
  say by storing the protocol name in the table and allowing a named
  protocol handler to interpret the contact address and sequence data
  independently. I don't mind either way.

- speaking ESMTP. I included native NNTP support in monotone because I
  thought it important to be able to be able to do *some* work with no
  external dependencies. this philosophy only goes so far though; for
  example I did not reimplement emacs or vi, but call them through a
  hook. a lua hook function to send packets via an external process
  will eventually be necessary. but should we include native ESMTP?
  maybe.


as far as other protocols beyond message-oriented services, I've
thought about it a bit but am not really settled on anything. some
points:

- I am unlikely to want the current monotone program to support
  running on an HTTP server (say, a CGI). there is a whole different
  league of reasoning for servers.  scalability, i/o, concurrency,
  data taint tracking, and general attack-resistance issues become
  dominant. I would not trust monotone to perform well in that
  environment, nor entirely safely. it was designed as a client.

- if supporting HTTP is really important, I could imagine implementing
  a small server-side CGI program which produces news-server-like
  semantice (a collection of immutable articles stored on disk, with
  monotonically increasing sequence numbers) which could respond to
  HTTP POST and HTTP GET requests. that might work well enough, and
  would make it easy to produce "private repositories" on any machine
  running apache, without bothering to set up INN. but such a program
  would have none of the database, delta, manifest, key and cert code
  which pervades most of the current 'monotone' program. I don't want
  "smart servers"; they're an invitation for attack.

- alternatively, we could try to support talking to webDAV or CVS
  servers directly. I have not explored the issues related to that. it
  seems monotone could be useful as "glue" to connect two or more
  organizational SVN/CVS servers together, without synchronizing their
  version numbering schemes. I'd welcome any thoughts or experiments
  on this.

probably any of these efforts need at least 1 enhancement in the short
term, which is 'authentication support'. NNTP, ESMTP, and HTTP all have
rudimentary (and important) mechanisms for client-side authentication.
we ought to support those.

-graydon