i actually started working on it before i knew postal-address exists - so no i'm not using it. However, i did base my datamodel on hr-xml standards for addresses, so it would be trivial to use the postal-address package instead of the one i have built into contacts. I'm just using mine for the time being since i'm used to it, but once i get to a more publishable state i can easily convert this to postal address. one concern i have is that postal address lacks some of the procs i use to speed up data retrieval and storage. maybe when i get close to publishing i can show you what i have and see how we can integrate them with one another. I actually think that the integration of addresses in contacts that i have is much more straightforward than having a seperate package - since persons or parties can be represented by an individual contact it makes user attribute retrieval centralized throughout the system. We can cross that bridge when it gets close to it.
I took a look at telecom and decided we didn't need it, though it would be easy to add. ultimately i decided that a simple text box would be more user freidly for us instead of having multiple boxes just for a phone number.
i built the data model with specific to datatype based storage in mind. what i mean by this is that it is easy to add a new storage type for the storage on things like phone numbers, which can be done via the telecom package or whatever. i mean it trivially easy - so i guess i could say it makes use of both, but i'm currently only using those widgets built into ad_form, and we don't have a telecom widget in ad_form yet so i'm not using it - i though having a number of fields for area code, country code and the phone number would be too confusing for our users (who admittedly are primarily north americans - that is why i made it simple to add a new storage type).
