On Sat, Jun 14, 2008 at 7:41 AM, Daniel Staal <[EMAIL PROTECTED]> wrote: > --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.)
Interesting. And being used on the NeXT argues even more against Mac:: or Apple:: as a prefix. > 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.) I think I like this best... Data::PList::XML (I'd use caps for the L). Because it is generically Data:: Only thing is, my utility only parses them, it doesn't write them. PLists are strongly typed and Perl isn't, so generating a PList out of an arbitrary Perl data structure is a little problematic... need to use a regex to see if it should be Integer or Real, but then how would you determine True or False? Data::Parser::PList could be the tool that reads them, and a subclass ::XML would do the dirty work. Other subclasses such as ::Binary or ::Text (for that NeXT format) could be added. > 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. I agree.
