Re: [LAD] Session Handlers and 'level 1' support

Regarding LADI Level 1...

On Fri, 8 Jan 2010, rosea grammostola wrote:

>> In signal handler function, a global variable can be set to mark that
>> save is needed. On next main loop iteration, the global variable is
>> checked and eventually save is made.

This totally confused me at first. "You're sending me a
UNIX signal... but then I'm supposed to answer back by
allocating a global variable? How do I do that?"

I think what you mean is to indicate that saving doesn't
have to happen in realtime, but that it can happen (for
instance) as part of the program's normal event loop. The
stuff about the global variable (or even an event loop) is
an implementation detail.

I suggest the wording be changed to say something like this:

    "The application, after receiving the signal, should
    save as soon as possible. However, the saving does
    not have to happen in the signal-handler function
    itself. (For example, you can push a 'Save Event' to
    your normal event loop.)

>> Save of the internal state can be made in a fixed file path, but it is
>> more useful to supply the file path through commandline. When
>> starting, app loads its internal state from the file specified. When
>> saving, app saves its internal state to the file specified."

This is also confusing wording (to me). Who is setting this
file path? And the commandline?? I thought we were
handling a signal.

May I suggest the following wording:

    "The application is free to save state however it
    sees fit (e.g. saving files to a fixed file path).
    When the application is started, some means of
    restoring the state needs to be given to the user,
    preferably from the commandline. For example,
    when the signal is received, the application will
    give a string id (such as a file path) to the
    user. This id may then be used as a commandline
    argument to restore the state."

I think this is a good idea (Nedko or whoever dreamed it
up), and I'm willing to add it to my applications.

Peace,
Gabriel
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jan 8 16:15:03 2010