Delete or clean client data

[diovudau]

When a client is removed from a session it leaves data behind.

This is both needed and undesired.

• It is needed because a removed client is not a final decision. If you close the session without save ("Abort") the client is still in the session and will be reloaded, with data, the next time.
• Having knowledge about the the exact files of each client also opens up more options for GUIs (optional convenience features outside and on top of the NSM protocol). Example: Client duplicate.
• The very nature of music production leads to lots of added and removed clients over time. This can lead to unwanted data, wasting space and the risk of the user losing overview and control.
  • @falkTX may comment on more problems through the not-so-random nature of client IDs

This is not a paradox. Cleaning up old clients need not be integrated into the existing remove functionality but could be an extra step with e.g. the option for the GUI to present a list of files and ask for confirmation. Or even cherry pick which old clients to delete.
However, that remains wishful thinking until there is a solution to figure out which files belong to which client.

Background information: Each client receives a name.ID combo to be used as name for the save-file. In an ideal world this will either be a single file or a directory with arbitrary content. Both variants make sure to find only the this clients data. However, it must be confirmed that these are indeed the only possible scenarios (according to the NSM API specs) and there is no chance of over-deleting.

[diovudau]

For a quick overview I added all available NSM-programs on my system into a single session and saved (all empty).

The NSM API mentions two variants: use name.ID directly as file or dir or append a file extension.

path_to_instance_specific_project is a path name assigned to the client for storing its project data.

The client may append to the path, creating a sub-directory, e.g. '/song.foo' or simply append the client's native file extension (e.g. '.non' or '.XML'). The same transformation MUST be applied to the name when opening an existing project, as NSM will only provide the instance specific part of the path.

There are many programs that use the file extension (All carla versions, JACKpatch, Non-Sequencer, QMidiArp, ZynAddSubFX, possibly more).

While the file extension cannot be known by nsmd nor the GUI it is a clear pattern still. If deleting client data is done in two steps I think this would be safe to work. An OSC message to request a list of clients files (in the subdir variant) and a second message to instruct nsmd to delete client files (not a list of files to delete, nsmd will fetch them on its own again).

Those two messages would be technically independent. A GUI like Argodejo should first ask for confirmation, presenting the list of files, then instruct to delete. But there are enough scenarios where a user knows exactly what is going on in the session-dir and just wants to send a script command to delete a client (for example in headless scenarios)

I can create a proof of concept version of that behaviour in Argodejo, to test if this is reliable and convenient. However, due to networked sessions in the end only the daemon itself (or rather the interconnected daemons) have access to their files.

[moonshaadow]

It is needed because a removed client is not a final decision. If you close the session with save ("Abort") the client is still in the session and will be reloaded, with data, the next time.

When loading an existent session, why not copying it in a temp file or directory ? In case of abort, the temp file is restored, so there is no risk of loosing data. You could safely delete client data when removing a client.

[diovudau]

Thanks for the good input. Working with temporary copies of files is an interesting concept in itself with many opportunities.

Some thoughts to explore the idea:

This is on such a fundamental level that any changes in this direction would need very careful planning and thorough testing.
Disk space and performance need to be taken into consideration. What happens when you save clients individually (and even from inside the client,without knowledge of NSM) and then press abort? What is the working session, the temporary copy or the original data?(->Power outage resets to last-opened state or last-saved state?)
This can be made easier and more secure with modern file systems that support copy-on-write but will that make this feature dependen on such or will it just be better on e.g. BTRFS?

It may sound less convenient than an automatic solution but a dedicated step to clean up a session (with user confirmation) might turn out to be a more robust approach, especially given that it is required not that often. And it is still better than cleaning up files by hand without the assistance of the session-knowledge.

Maybe there are aspects of this idea, and its further development, that can be integrated safely without changing the expected behaviour from a users point of view. Expected behaviour is either explicitely stated in the docs or implicit computer-desktop conventions.