Re: [Monotone-devel] mtn automate tcp

[Thomas Keller]

Ulf Ochsenfahrt schrieb:
> 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.

This would indeed be a problem. But now since automate commands can take 
options it should be relatively straight forward to feed in some key id 
to authorize certain actions. Now whats missing is an internal 
authentication layer which allows/disallows things. And it might be a 
bit tricky to load all that into automate, since this was/is supposed to 
run in a "trusted" environment - the user's profile and/or workspace. 
Hrm... maybe its not that good idea...

> 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.

Only hard errors exit the instance (i.e. which make stdio unusable for 
further commands), others should just print out the error and continue 
to serve. If there are recoverable errors which exit the instance, then 
this is IMHO a bug.
Of course error codes and general error handling could deserve an overhaul.


> 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).

I've voted for some automate change_working_dir for a long time, but 
this wasn't accepted. I don't remember what the actual problem was with 
it, but I'd like to see that coming up even independendly from 'automate 
tcp' =)

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

This is just because there is not enough man power involved (most of the 
commands require a lot refactoring since automate.cc isn't yet split 
like command.cc is). Also, writing data via automate in general is also 
another cup of coffee i.e. its undecided what should happen when merge 
conflicts pop up, as no program can be executed.

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

There is absolutely no concurrency in stdio today and I doubt it is 
useful to allow such things when stdio works on a single db in the 
backend since their access would need to be streamlined anyways. So if 
an action is running, the service would probably need to give some 
"busy" signal back to the calling request.

Thomas.

--
- "I know that I don't know." (Sokrates)
Guitone, a frontend for monotone: http://guitone.berlios.de
Music lyrics and more: http://musicmademe.com