I’m torn on implementing this feature. Raccoon v3 had it, it was pretty popular with power users. It was suppose to be reintroduced in Raccoon v4.1 (Google’s latest protocol changes forced an early release), but I don’t really want to do it.
The problem with the commandline is it being a quick and dirty way to implement features for power users: fairly isolated code and almost no UI bloat. Takes a fraction of the time you’d have to spend on creating a dialog window and you always end up regret doing it afterwards because eventually regular users will want to use the feature, too and then you have to explain to them how to use the commandline. You initially save time on coding, then waste it all again on email support.
The next problem with adding a commandline mode is that Raccoon v3 kept everything in the filesystem, so running multiple instances of the software wasn’t an issue. With v4, however, it is, since all meta data is now kept in an embedded SQL database, which can only be opened by one process at a time.
The choice here is either running the database as a background daemon for multiplexing access or risking that GUI and a CLI instances will block each other. Neither is particularly appealing! Both will be a cause of later regret.
The solution I currently fancy is to temporarily implement a command line switch for updating apps that will be deprecated from the beginning and have “here be dragons” as its sole description. Then eventually have Raccoon run as a servlet as well as a desktop application (see TradeTrax for an example).
