4 ms·

Looking at the `sq` command line client doesn't instill hope to me that it is going to be friendly: https://docs.sequoia-pgp.org/sq/index.html https://docs.sequ

by eterps 8y ago

Looking at the `sq` command line client doesn't instill hope to me that it is going to be friendly: https://docs.sequoia-pgp.org/sq/index.html https://docs.sequoia-pgp.org/sq/index.html But if it's at least going to be consistent that would already be a big win.

dmoreno 8y ago
Now it needs a --output=json option to make it awesome and usable from scripts and programs.
- nwalfield 8y ago
  We've been considering this, but we'd rather have people use the library. We already have the start of a Python interface, which is pretty easy to use, IMHO. But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.
nwalfield 8y ago
What would make a friendly interface in your opinion? The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.
- eterps 8y ago
  I have nothing against the git style subcommands, in fact I think they are great. A friendly interface would in my opinion be from the perspective of an end user. In the case if GPG the end user can have a couple of goals in mind, to encrypt, decrypt or sign data. Although you could do a lot more things, for most users those would be secondary goals. I guess the average user doesn't necessarily know about autocrypt, ASCII armor, OpenPGP packets etc. Those users would have to guess whether they need to (do I need autocrypt? Why isn't it a default?). To be honest I don't think the usage output is very bad in its current form, but as a start for something that will evolve over the years I am not so sure.

by eterps 8y ago

dmoreno 8y ago

Now it needs a --output=json option to make it awesome and usable from scripts and programs.

nwalfield 8y ago
We've been considering this, but we'd rather have people use the library. We already have the start of a Python interface, which is pretty easy to use, IMHO. But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.

nwalfield 8y ago

What would make a friendly interface in your opinion? The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.

eterps 8y ago
I have nothing against the git style subcommands, in fact I think they are great. A friendly interface would in my opinion be from the perspective of an end user. In the case if GPG the end user can have a couple of goals in mind, to encrypt, decrypt or sign data. Although you could do a lot more things, for most users those would be secondary goals. I guess the average user doesn't necessarily know about autocrypt, ASCII armor, OpenPGP packets etc. Those users would have to guess whether they need to (do I need autocrypt? Why isn't it a default?). To be honest I don't think the usage output is very bad in its current form, but as a start for something that will evolve over the years I am not so sure.