On Mon, 7 Apr 2014 23:10:03 Tobias Ellinghaus wrote: > Am Montag, 7. April 2014, 20:48:35 schrieb Alexander Wagner: > > On 07/04/14 14:55, Tobias Ellinghaus wrote: > > > > Hi! > > > > >> I can understand why it may be undesirable to have, perhaps multiple > > >> instances of, the cli concurrently accessing the database when the gui > > >> may > > >> be active - if the cli updates the database.. > > >> > > >> Does the cli need update access to the db? > > > > > > No, and using anything from the database is certainly not advised. If I > > > ever find the time I will probably rewrite dt-cli to not use a database > > > at all and maybe even skip the usage of dt_init() so that the --core > > > would go away, too. That is all just slow and bloat. That tool isn't > > > meant to be a remote control of darktable (using --core --library > > > ~/.config/darktable/library.db you could even import images from the > > > command line without having a running dt around) > > > > What is bad about this? This can could in quite handy... IMHO there is > > no need to strip this entirely. > > It is slow.
While this may be so, it is the cli where response times are not as important. I use the cli in "real time" but also via a Linux cron.daily script. In the latter case, this happens at around 03:00 so response time is not an issue. The reason that I'm in favour of retaining access to the DB is for access to styles. ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
