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 <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
