Consider adding a CLI daemon for background work

[korydraughn]

Feature

Having a daemon would enable us to improve the user experience around iRODS.

For example, the daemon could manage a queue which allows users to schedule multiple uploads of files. Users would then be able to query the queue for status updates, etc.

This is just one way to use the daemon. There are likely other ways to take advantage of it.

[trel]

But... this is a client? Who's running the daemon? When?

[korydraughn]

This is just an idea. The daemon would be a service that is managed by systemd. Just like how Docker has a daemon which manages things.

The CLI daemon could be used for several things (e.g. tab-completion, caching, etc). Ultimately, it gives people a way to stack operations in the background without having to give up control at the terminal.

[trel]

This is running on the irods-server? Or on the client machine?

[korydraughn]

On the client machine.

[trel]

Okay, your docker comment confused me, that daemon runs on the 'server'.

[korydraughn]

Let me try and clear it up.

I'm saying the CLI can have a daemon that runs alongside it on the user's local machine. So the CLI consists of two components.

• The command line binary which is directly used by a person
• The daemon which runs locally in the background by some init process
  • The daemon does NOT run on the iRODS server

I'm thinking about how this can handle uploads of many small files in a parallel manner.

[trel]

if that's the use case... feels like we can tar/zip, upload with a flag for 'batch' or 'policy', and then after receiving the server can unzip and register... all at once (batch) or one at a time (policy) (or perhaps concurrently via some synchronous server-side mechanism).

whiteboard!