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.

> 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.

> Core voted against XML plists in /etc. I think it would be a pity
> to lose the option to use proplib for configuration files, so I
> went ahead and designed something that would hopefully be considered
> sufficiently "user friendly" for the purpose (the key seemed to
> be "look a bit C-like" and "keep syntax overhead minimal").

Then I think the issue needs to be discussed some more w/ Core.  I'm  
having lunch with some Core folks today, I'll bring up the topic.

> Obvious implication of this is that the format follows my personal
> taste.
>
>> All you XML haters need to just get over it.
>
> 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.

I just don't see any compelling reason to have an additional plain- 
text encoding that has no technical advantages over the extant plain- 
text encoding and still doesn't solve the problem of everyone-can-edit.

-- thorpej