2008/1/31, Zack Weinberg <[EMAIL PROTECTED]>: > 2008/1/30 Zbigniew Zagórski <[EMAIL PROTECTED]>: ... > > > > In current state this option will affect password prompt only, but it > > can be used in future commands to check if user wants to make decisions. > > I approve of the concept in general; however ...
Good. > > After five minutes it appeared that almost all functions from keys.hh > > must accept app_state& instead of lua_hooks& only: > > I have to veto anything that does anything like that, because we're in > the process of removing the app_state structure altogether. I'm in I was not aware of this fact :/ That's a pity. > the middle of rototilling keys.cc and key_store.cc right now and I > can't guarantee what they will look like when I'm done, but - I expect > that the right thing for you to do is save the option in the key_store > object when that object is constructed, if that makes sense? I'll look at this and in general i'll look at those changes. I understand that you're speaking about experiment.encapsulation branch. > Also, I wonder if a --passphrase-fd=NUMBER option would make sense for > your work. This idea comes from GPG - if the option is given, > monotone would read any passphrase it needs from that file descriptor > rather than the terminal. You'd make the file descriptor a pipe, and > if monotone tries to read from it, pop up a password-prompt dialog > box. (I don't actually know how to code that on your end but I'm sure > it's possible.) Well it's a great idea, i though about that. However ... I'm almost sure that we don't want to touch file handles inheritance/passing between process on win32. Simply I don't know how to do that (I know only about inheritance). (+1 for simple and clear POSIX/unix architecture) Second. For example java library gives you possibility to control only stdin/stdout/stderr inputs of subprocess. And we want/need some java interfaces to monotone. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy /
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
