Who's the more foolish: The fool, or the fool who follows him?

Over at daringfireball, John writes:


He does have a good technical case for why Apple might want to do this. His argument, more or less, is that Apple doesn’t need to be protective of the source to these apps (e.g. Mail, Safari, iCal, iChat) for competitive reasons, because they’re inextricably tied to Mac OS X technologies like Cocoa. If they released the source to iCal, it’s not like it would be that much of a help in allowing someone to port it or knock it off on Windows or Linux. It’d probably be easier to do a rip-off of these apps on another platform by completely re-implementing them rather than using their actual Cocoa source code.

<yoda>mmm, probably for some, probably not for others</yoda>

NSColor archiving weirdness

This is what an NSColor looks like in a xml keyed archive:

  <dict>
   <key>$class</key>
   <dict>
    <key>CF$UID</key>
    <integer>18</integer>
   </dict>
   <key>NSColorSpace</key>
   <integer>1</integer>
   <key>NSRGB</key>
   <data>
   MC4zNzY0MDQ0OSAwLjUxMTIzNTk1IDAuNjQ5ODEyNzYgMC42MwA=
   </data>
  </dict>

There are numerous variations on this, but it is basically a color space and then appropriate values. Since this is a property list the gook between the <data>'s is base64.

Now, the question at hand is, what's in the data? The first instinct might be perhaps that since this is an NSData, the information is binary encoded, perhaps some big endian floats or doubles? Nope. Perhaps some super secret binary format? Nope.

It's just an ASCII string:

MC4zNzY0MDQ0OSAwLjUxMTIzNTk1IDAuNjQ5ODEyNzYgMC42MwA=

Equals:

0.37640449 0.51123595 0.64981276 0.63

Now at this point you're kind of going "So f'ing what?". Well, I'm saying "What the f?"

What is the reason for doing this?

Space savings? Not really.

<data>MC4zNzY0MDQ0OSAwLjUxMTIzNTk1IDAuNjQ5ODEyNzYgMC42MwA=</data>
<string>0.37640449 0.51123595 0.64981276 0.63</string>

<data>MAA=</data>
<string>0</string>

Speed? Nope. The base64 adds yet another layer of parsing at the very least.

Precision? Nope. They represent the same thing.

Obscurity? Barely.

Backward compatibility? With what? keyed archivers are relatively new.

Care to guess? Even in binary archives this decision makes little sense.

Keyed archives provide this nice way of generating human readable archives and yet NSColor ruins the party and writes out strings as data. We waited so long for text archives and this is what we get? Bleh.

keyedobjects.nib typos

While working on .nib unarchiving code I ran across a spelling error and a typo in Apple's keys.

NSBrowser:

   <key>NSPreferedColumnWidth</key>
   <real>100</real>

NSTextView:

   <key>NSMinize</key>
   <dict>
    <key>CF$UID</key>
    <integer>61</integer>
   </dict>

Should be NSMinSize.

Should I file a bug? :) I should file a bug on Property List Editor though, it can't handle keyed archive property lists.

Yes, we have this kind of flooring too ...

... but a quick vacuum takes care of it.