Markus Schiltknecht schrieb:
Regarding the deferred failures: maybe we need to add options like '--read-only-db' or '--no-workspace' to automate stdio and make it check right from the start. So if a 'mtn -d test.db --read-only-db automate stdio' starts up correctly, you can be sure to be successfully connected to a read-only database.
Right now (I think since 0.33) a database check is performed, just because I inserted an "app.db.ensure_open();" call in AUTOMATE(stdio), but this is a really ugly hack, because it assumes that all automate commands need at least a valid database (but f.e. the new automate identify does not). A check for a valid workspace is completly missing. So using options for stdio to define what we're actually trying to do is quite a good idea. However I wouldn't make these single options, rather than put them as arguments to some --mode or --access option. I don't know if I need to have such fine-grained options here, probably
workspace,read workspace,write database,read database,write would be enough for me. On the UI side of things one would do $ mtn automate stdio --access workspace,read --access database,read to combine several of these options. Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.thomaskeller.biz > Music lyrics and more: http://musicmademe.com _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
