Re: [LAD] LASH - some questions & comments

On Thu, Oct 16, 2008 at 11:40:09AM +0300, Nedko Arnaudov wrote:

> The trend is to remove usage of argv at all. As for documentation, I
> agree LASH needs better one. In current documentation (somewhat out of
> date), argv thing is supposed to be opaque. I.e. LASH app should not
> know what lash specific arguments are.

That exactly is the problem. Any app should be allowed
to know. Elementary courtesy towards your client...
Support libraries are not meant to be 'stealthy'.

Looking at the source, there's indeed a lot of
deprecated stuff, followed by two flags, and then
the complete argv minus the lash-specific parts.

I don't think blindly copying the complete argv
and giving it back when the client is restarted
later by lash is a good idea.

If there is any data in there that is essential
for the client to be restarted later, then the
client would probably include that in its configs
or in its saved config file.

The only exception would be things that are essential
even before the restarted client connects to lash.
But only the client knows which data that would be.

So it seems it would be a better approach to let
the client supply those parts of its argv that it
wants back the next time, if any, rather than just
taking it all.

This issue (and some others, like jack connections)
is not as simple as it seems.

For example, none of my (GUI) apps knows if any
of its configuration comes from compile-time defaults,
/etc/appname.conf, ~/.appnamerc, ~/Xdefaults, or
the command line. They just interrogate the X11
database which combines all of that with the right
priorities (part of libclxclient).
Some of that data may be pointers to application
resources (e.g. the instrument definitions used
by Aeolus) rather than user options. Such resources
may have been moved or replaced next time lash runs
the app. In that case the app wants the current
values, not the old ones. But only the application
knows such things, so blindly copying everything
is not the right way. Since the app is given the
chance to store its config in any way it wants,
it isn't necessary either.

Ciao,

-- 
FA
Follie! Follie! Delirio vano e' questo!
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev