[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] minor update
From: |
graydon hoare |
Subject: |
Re: [Monotone-devel] minor update |
Date: |
24 Apr 2003 09:15:30 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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