|
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. SecurityAnyone 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 HandlingRight 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 Directoryautomate 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 Operationsautomate stdio doesn't support such basic operations as add, drop, rename, or commit.
5. Multiple AccessYou'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
smime.p7s
Description: S/MIME Cryptographic Signature
[Prev in Thread] | Current Thread | [Next in Thread] |