--As of June 13, 2008 8:35:36 PM -0500, Chris Dolan is alleged to have said:
Note that plists can also be stored in a binary format; would you
want to support that also? If so, how about Parse::ApplePlist?
I don't know anything about the binary format.... but its existence
does argue against the XML prefix for sure.
On a Mac, you can use "plutil -convert xml1 -o out.xml in.xml" and
"plutil -convert binary1 -o out.xml in.xml" to switch back and forth.
You can also use the -lint option to validate your data files.
I *think* the binary format was introduced in 10.4, but maybe it was 10.3.
--As for the rest, it is mine.
There's also an old text format version of them that goes back to when they
were used on NeXT, which is being phased out. (I think.)
I'd go with XML::Plist myself, if that's all you are working with. If it's
a more general plist parser, I'd go with something like Data::Plist::XML
(Where you could then write sub-modules for the different formats they are
saved in.)
You could also use PropertyList in place of Plist in any of them, which
would be easier to understand what they are for those who *don't* have
experience with property lists. However, it would make it harder to find
for anyone who's trying to find a tool that works with them. (As all the
documentation generally refers to them in the short form.) Personally, I'd
say call them plists, and explain in the docs: The people who use this are
likely to be looking for something that works with some file they've
already got, and so will know them by that name.
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
