Jeff Schroeder wrote:
On Thu, Apr 15, 2010 at 9:00 AM, Dmitri Pal <dpal(a)redhat.com>
wrote:
> Jeff Schroeder wrote:
>
>> On Thu, Apr 15, 2010 at 8:09 AM, Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
>>
>>
>>> On 04/15/2010 11:07 AM, Tomas Mraz wrote:
>>>
>>>
>>>> On Thu, 2010-04-15 at 09:23 -0400, Stephen Gallagher wrote:
>>>>
>>>>
>>>>> Can we please come at this issue from the right direction? The
reason
>>>>> that this is even being debated is because we learned of another
program
>>>>> (certmonger) that is using INI files to store binary data.
>>>>>
>>>>> THIS IS WRONG.
>>>>>
>>>>>
>>>>>
>>>> ...
>>>>
>>>>
>>>>> In conclusion: I think attempting to solve the newline/escape problem
in
>>>>> libini_config itself is both too complex and too limiting. It is
more
>>>>> complexity being added to the libini_config than a simple INI file
>>>>> parser needs to have, and by implementing any particular approach to
>>>>> managing the data, we are limiting is usability to only those
use-cases
>>>>> that we can come up with.
>>>>>
>>>>>
>>>> Not that I am really part of the SSSD project, but +1 from me anyway.
>>>> Very sensible reasoning.
>>>>
>>>>
>>>>
>>> Actually, input from outside our project is probably more valuable. We
>>> intend for libini_config to be available for use by any project that
>>> wants it.
>>>
>>>
>> Alright well corner cases and "magic" handling of multiline stuff
>> seems wrong. Be dumb about it and let the caller of your library
>> figure some of that out. If someone wants to store binary data in an
>> ini file, let them. That seems slightly insane, but it is their app.
>> That doesn't mean you should hack up your library because your users
>> want to do stupid things.
>>
>>
>>
> Well I generally disagree with the approach. I think that if I sell a gun
> it should be suitable for shooting yourself too (big time).
> But OK. This discussions boils down to "be dumb and
> not handle more than you need to" and everybody seems to agree with this.
> Fine, it will be what Steve suggests then: no escapes and RFC822.
>
> I still feel that we should be nicer to "crazy" people and let them
> "abuse" what
> we offer and offer more convenient options with which they can shoot
> themselves
> in all sorts of different ways. :-)
>
> But I will comply.
> Thank you for your time and input!
>
It is just a difference of design philosophy. Much like in the ruby
community Ruby On Rails includes everything and tries to be magical
which makes it slow vs the merb approach of small, light, and fast.
Neither are wrong but merely different.
Thanks for being pragmatic and please keep on writing awesome
software. As a user I can't thank you enough.
Thanks for the warm words. You really made my day!
--
Thank you,
Dmitri Pal
Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/