On Jun 25, 2007, at 9:25 PM, Thor Lancelot Simon wrote:

> 1a) Never responded -- at all -- to those who asked you whether  
> Apple's
>    UI team would actually permit a developer to force normal users to
>    read or edit proplist XML plists (I think it's pretty blindingly
>    obvious that the answer is "no")

So, as someone who happens to work for Apple...

In some forums, end-users / administrators are encouraged to edit XML  
plists in their text editor of choice.

Let's take a step back here -- Apple's HI team focuses on "grandma  
reading her email and video chatting with her grandkids".  The focus  
there is "make it work without any configuration at all".

But there are a lot of folks at Apple who deal with advanced users,  
server administrators, etc.  And those folks DO encourage people to  
edit XML plists.  I can think of a half-dozen examples just in one day  
at WWDC07 alone.  And, quite honestly, in all of my dealings with  
those Apple end-users, I have yet to hear a single complaint.

> 2) Never responded in any substantive manner to the objections of  
> those
>   who noted that the XML plist format has serious usability issues  
> as a
>   format to be read or edited by humans

If you're spending that much time editing config files, you have  
bigger problems.  Besides, what do you want me to say?  Ok, here's my  
response -- I think that the cross-platform compatibility benefits of  
the XML plist format outweigh any minor inconvenience that a human has  
when editing such a file.  I'm not going to be persuaded otherwise,  
because my fairly extensive real-world experience with this format  
tells me that it's just not an issue.

> 3) Never actually offered any explanation of why a more human-friendly
>   plist externalization would be problematic, in applications where
>   there is a high likelihood that human beings would have to edit  
> plists,
>   restricting yourself (uncharacteristically, and for some reason I  
> really
>   do not grasp) to irrelevant and inaccurate invective such as the  
> above
>   quoted "N-I-H nonsense."

I can't state it any more clearly than this:

XML plists were chosen specifically because they provided the  
flexibility I wanted while also using a format that is in wide-use by  
other platforms.

I have stated this as my reasoning before.  All we're doing with  
alternative formats is wasting our time stroking our own egos because  
"we can do it better, hah!"  Sometimes it just doesn't matter if you  
can make it a little better.  Sometimes the effort is better spent  
actually developing a solution on top of the infrastructure.  How much  
time was wasted on this proplib nonsense that could have been spent on  
the actual SoC project that is using proplib?  How much time will be  
wasted documenting two serialization syntaxes for every app that  
decides it wants to use proplib?  It's just stupid to have both.

> Since one of the very nice things about proplib is that if you want  
> XML
> (or any other supported format), the library can always give it to  
> you,
> it's really hard to see why the only position in this conversation  
> that
> the phrase "N-I-H nonsense" applies to is not, in fact, yours.  What
> harm, exactly, does it do you if some other people, who find that they
> need to edit plists by hand, prefer to do so in a syntax they find
> easier to use?  If you find that syntax so offensive, you can always
> have proplib give you the XML you prefer instead.

Well, you know, I never really liked the BIND domain file syntax.   
Let's do another one!  How about for every other config syntax in the  
system!  That's great!  More choice!  Choice is good!  This is going  
to be as cool as having 37 different toasted oat O-shaped breakfast  
cereals to choose from!

> If you're worried about compatibility between proplib implementations,
> perhaps a more constructive thing to do would be to have Apple's  
> library
> take advantage of the convenient BSD-licensed code for SCN format now
> available in NetBSD.  But don't shoot the messenger!

What would be the point?  It would pretty much never happen.  Besides  
the "Why would we want to do that?" response that would surely elicit,  
it's not like the implementations are at all related, so the code  
couldn't be used in any case.

> As a practical matter, just about everyone else seems to like this  
> format,
> so it is probably going to stay -- just as the XML format is.

I'm so sorry I ever wrote proplib in the first place.  I meant to  
provide an enabling technology, but all I did was provide a platform  
for people to make stupid decisions.

-- thorpej