General strategy to stay up- and downwards compatible with Non-Session-Manager sessions

[diovudau]

Not only is New-Session-Manager a drop-in replacement for Non-Session-Manager but sessions must stay compatible in both directions. Obviously New-SM can load Non-SM sessions just fine, and currently the reverse is also true. And it shall stay this way.

However, if we want to save more this MUST not change the original session.nsm file format.

The file loading code is a straightforward line-by-line lookup with : delimters in a fixed order to parse values.
while ( fscanf( fp, "%m[^:]:%m[^:]:%m[^:\n]\n", &client_name, &client_executable, &client_id ) > 0 )

Adding or reordering fields is impossible and will not happen, period.

One strategy is to have a second save file. Original NSM never deletes or changes files that is doesn't know or control, which is good for multiple reasons (storing extra files in the session dir, such as an .odt with song lyrics etc.). This should be a format chosen and designed to be up- and downward compatible with past and future New-SM versions. This is another topic for discussion, so only briefly: Uncomplicated stable syntax, don't change or delete values you don't know but save them unchanged, API version saved in the file.

If that turns out to be impossible or impractical there is another route, which I tested in Argodejo: Extension-Clients that exist to store and read data, most likely to be read by the GUI. Communication and handshake with the environment is done over the existing broadcast channel. The nsmd server does not need to know anything about it, no changes to the API required. For the nsmd server these extension clients looks like any other client, thus the session can be loaded in any host, even if that does not support these additional features.

[diovudau]

This strategy has worked so far and was adopted as default method.
This reminder can therefore get closed.