Re: Package Proposal: Vcard_Parse

<pjones@ciaweb.net> wrote : > Hi, Bertrand, > >> It would be nice if you add two things: >> >> 1. Remove the invisible chars in the MacOSX address book vcards >> automatically (you can use str_replace() with chr() and ord() to do >> that). > > I agree that it would be nice. :-) However, I'm having trouble > getting file() to even *read* the .vcf file generated by my mac OS X > Address Book app (but it appears only Mac at work generates those extra > chars -- beginning to wonder if it's a phenomenon specific to the work > installation, not to Address Book in general). It must be your work install then. I have tested with my Address Book app on OSX and it does not return any invisible chars. >> 2. Create a writer in complement to the parser. > > Am working on that now, in conjunction with a vCard "contacts" > sub-application for my Phorecast project. It'll probably be a separate > class, as there are good vCard-writers out there now, and choice is > good. If you are currently working on it now, I don't see the need to have a parser and a writer as 2 different classes. VCards don't need that much overhead IMO. To keep it simple, I would recommend that you put both parser and writer into the same class, this way it will be easier for users to know which class to use as there will only be one. It's always easier to require only one file, and in the end, you will notice that you will want your class to manage your contacts, for example create new ones, delete some and write the new file to disk. With 2 classes, you will need a bridge class. Make sure it writes vCard in 2 and 3.0 formats though... ;) >> Other names for your class could be : >> >> Contact_vCard_Parser >> Contact_vCard_Writer >> or simply Contact_vCard if you implement both in the same class >> (recommended >> way) >> Or Address_vCard >> >> As we already have a Genealogy_Gedcom. >> >> Then, it might fit in the file formats category on pear website. > > I think File Formats is going to be the proper category. The only > problem will be the super-prefix (Whatever_Vcard_Parse) for the class. > In reference to the RFC2426, which defines the vCard format... > > The schema is based on the attributes for the person object defined > in the X.520 and X.521 directory services recommendations. The schema > has augmented the basic attributes defined in the X.500 series > recommendation in order to provide for an electronic representation > of the information commonly found on a paper business card. This > schema was first defined in the [VCARD] document. Hence, this [MIME- > DIR] profile is referred to as the vCard MIME Directory Profile. > > ...perhaps the super-prefix should be X500 so that other X500-derived > classes can fit within the same naming convention? E.g., instead of > Contact_Vcard_* or Address_Vcard_* it could be X500_Vcard_*. Unless > that's too inelegant. X500 doesn't mean anything for me, it's too cryptic. I guess you will have to choose and propose a name like those: - Contact_vCard - Address_vCard - File_vCard The logic behind the name is that we have a Genealogy_Gedcom and a Spreadsheet_Excel_Writer. You see that the prefix actually defines the domain it is mostly used in. Excel is a spreadsheet app while Gedcom is a common format for genealogy files. vCard is a common format for dealing with contacts or addresses... IMO, File is too general. These are only suggestions for your package, feel free to do what you want with them. Bertrand Mansion Mamasam