monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] mtn automate tcp


From: Ulf Ochsenfahrt
Subject: Re: [Monotone-devel] mtn automate tcp
Date: Fri, 17 Nov 2006 14:47:53 +0100
User-agent: Icedove 1.5.0.7 (X11/20061013)

Lapo Luchini wrote:
I was thinking... wouldn't a "automate tcp" be useful?

I mean something that just accepts TCP connections and then talks the
"automate stdio" protocol: having an always-on server listening on
127.0.0.1:something could be very nice e.g. from PHP access, when it
would be difficult to maintain an open "automate stdio" available from
all workers.

Or there is some problem against that I cannot see right now?

    Lapo

PS: this could be easily done using "tcpserver" but that would accept
only one connection at a time, for file-locking problems, isn't that so?

Hi!

This approach has multiple problems (and probably more I'm not aware of right now):

1. Security
Anyone who can connect is allowed unlimited access to your db. Even if you only allow connections from localhost, you can run into problems on multi-user systems. You could, however, add an authentication layer before you actually allow operations.

2. Error Handling
Right now, automate stdio handles errors by exiting the mtn instance. So you'd need to be able to start a new 'server' from your php/java/c/whatever anyway.

3. Working Directory
automate doesn't allow you to change the working directory. So you couldn't use it to handle workspaces (or only at most one).

4. Limited Operations
automate stdio doesn't support such basic operations as add, drop, rename, or commit.

5. Multiple Access
You'd need to figure out some way to handle the locking issues you get with multiple concurrent access.


Now, in my opinion it isn't such a bad idea. I'm favoring a solution where mtn automate stdio works like a monotone shell, where you can issue all kinds of monotone commands. Error situations would result in error results (automate stdio provides for reporting error codes, but this is often not used and instead, the mtn instance is simply exited - imho this severly limits the usability of automate stdio). This approach could solve 2, 3, and 4.

Cheers,

-- Ulf

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]