On Thu, Jun 30, 2011 at 1:20 AM, Andrew Hutchings <[email protected]> wrote: >> I don't get why. Still the question remains - if Boost is unwanted for >> the client, what additional benefit does the parser provide to >> drizzled. It would make more sense that all components use one and the >> same parser to read the same config file. (Ie, if client can't use >> Boost, then drizzled should use the home grown one.) > > 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). henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
