On Thu, Jun 30, 2011 at 8:51 PM, Henrik Ingo <[email protected]> wrote: >> For a client library we want as little dependencies as possible. In fact I >> can't see why a library will need a .ini file. In my opinion the client app >> should have the .ini parser and use function/method calls to setup the >> library. >> >> Drizzle client apps should and will use the Boost .ini parser. > > Ok, this separation makes sense to me. Ie your answer to my original > question is that there should be no home grown parser, rather drizzled > and client apps use the boost parser and the libdrizzle library has no > parser at all. Correct? > > If someone wants to embed libdrizzle in their application, they could > then separately also include the boost library for parsing ini file, > should they want that functionality. Is this correct? > > This is not an area I have a lot of expertise in, but my intuition > says many app writers would actually appreciate if libdrizzle had the > ability to parse the ini file. In some cases I wouldn't of course want > to connect to the default drizzle/mysql instance, but it's still > convenient to let libdrizzle parse a custom ini file > (--defaults-file=...) rather than being forced to pass every parameter > from the app (where the app would need to read them from a > configuration file anyway).
When connecting to the default server it's even more important. The default server might not use the default port or the default socket file. It might not even run on localhost. That's why, like MySQL, I'd like to add this part to the lib itself. -- Olaf _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
