Re: [LAD] LASH - some questions & comments

On Thu, 2008-10-16 at 00:10 +0200, Fons Adriaensen wrote:
> Some questions and comments regarding the LASH release candidate.
>
>
> 1. lahs_init()
>
> Would it be possible to document the contents of
> the first argument 'lash_args_t *args' ?
> I'd be happy to give lash all the info it needs
> but feel quite strongly that I should be able
> to provide this myself and not being forced to
> have liblash inspect/mangle my argv. See also 2.

The issue here is that lash arguments are properties of the particular
session that the client is loaded into. LASH takes the responsibility
of being aware of the lash session out of the hands of the client. In
the case of argc/argv, this isn't just a convenience thing but, as Nedko
noted, a deliberate opacity.

Originally, clients that wanted to be aware of the lash session would
had to have been Server Interfaces. That whole business was messy
anyhow.

> 2. lash_extract_args()
>
> The type of main()'s argv is char *argv[], so
> why is the second argument a triple pointer ?
> Re-arranging the elements of argv does not
> require access to the variable argv itself,
> only to its elements, and for this a double
> pointer is all you need.

I think the better option would have been to use environment variables
rather than command-line arguments. That would have required no
fiddling at all. As for why a double pointer was used, it was likely
because I was following the method used in GTK+ et al.

> 3. The Restore_Data_Set event.
>
> How does a client know when all configs saved
> by a previous session have been received ?
> The client may be updated meanwhile and
> expect more configs than were saved. It
> should have defaults for these of course,
> but how long should it wait for data that
> may never arrive ?

The philosophy here is that the client's state is the client's business.
The schema it uses to store its state is up to the client; the configs
simply provide a method of doing so.

In your example, the client isn't saving its state *as a whole* but
simply storing data for individual configuration options. In order to
save the entire state, the client would have to store information about
which configuration options were saved.

The name "config" may be misleading.

Bob

-- 
Bob Ham <rah@email-addr-hidden>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev