[LAD] LASH - some questions & comments

Nedko Arnaudov nedko at arnaudov.name
Thu Oct 16 08:40:09 UTC 2008


Fons Adriaensen <fons at kokkinizita.net> writes:

> Some questions and comments regarding the LASH release candidate.

Nice to get lash-0.6.0.~rc1 reivewed by you Fons! Thank you!

> 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 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.

> 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 spoted this too, when I was doing python bindings some time ago. I
think I got response something like "it is for consistency". OTOH the
important part is that we dont want to brake existing apps by chaning
the API. The plan is to introduce entirely new API. That should fix all
known issues. Disclaimer: Other LASH project members may not agree on
these statements.

> 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 ?

Good point! AFAIK client cannot know this. I'll write it as comment for
our new API ticket (#14) so we address this issue when designing the new
API.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20081016/f32b4eca/attachment.pgp>


More information about the Linux-audio-dev mailing list