# Jason Thorpe 2007-06-26:
> On Jun 26, 2007, at 8:51 AM, Jachym Holecek wrote:
> >I'm aware of this. The rationale behind exposing object internals
> >in a (private to the library) header file is that codec  
> >implementations
> >need access to them, and it seems better to keep codec code in  
> >separate
> >files rather them spreading per-codec ifdefs in object  
> >implementations.
> 
> Actually, I think what it really shows is that it's not all that great  
> to have a proliferation of encodings.

I don't think it does -- let's just agree to disagree on this point.
I simply don't see any problem with a small C library having its internal
structures defined in single private header (ie. don't see the benefit of
applying given design principle to small-library's-internal-internals so
verbatimly).

> >Also note that (related to the private discussion between the two of
> >us and dillo@ a couple of days back), at least dictionary/array locks
> >need to be reachable by non-object-specific parts of proplib.
> 
> Can you please be specific?  I don't seem to recall seeing any such  
> mail about that.

Sure, see offlist mail.

> >Don't put feelings into my head -- I don't hate XML, I just don't
> >passionately love it. In practice, I find hand editing XML less
> >painful than some of the traditional UNIXy text formats (but more
> >painful than some others).
> 
> I don't passionately love it, either.  But, honestly, I think people  
> are imagining things when they think there will be this huge problem  
> with people editing XML property lists.  I have a significant amount  
> of real-world experience with people actually doing this, and it's  
> just not a problem, in practice.  For cases where it might be a  
> problem, we're better served by a property list editing tool that  
> works with the XML encoding as well as the forthcoming binary encoding.

A specialized editor seems to follow "one size fits all" approach
so I'm not sure it solves the problem either -- but then I haven't
seen one yet.

I'm curious about the outcome of the "XML in /etc" lunch.

	-- Jachym