contacts kit

In these weeks i have improved the contacts kit core in order to have enough support for the formats supported. The vcard and people translators can now translate and exchange many types of field, though photo and groups aren't yet supported.

Main functionalities of the classes :
BRawContact
Their functionality is to deal with the BTranslatorRoster and keep track of basic informations, like the final format. The final destination is represented as a BPositionIO object. Basically the class find a suitable translator when initialized and provide two methods : Commit() and Read(). The first has as argument a BMessage that contain Flattened BContactFields, the second translate the source file (that can be a B_PEOPLE_FORMAT, B_VCARD_FORMAT, B_CONTACT_FORMAT) into a BMessage and return it.

BContact
BContact is the high level class representing a contact, it has the job to store informations about the raw contact, provide methods to add/remove/replace/compare the BContactFields. When initialized it use the BRawContact::Read() function to read fields from a location, and use BRawContact::Commit() to provide BContact::Commit().

BContactField and childs

BContactField is designed to support as well both People and VCard formats. The class is not intended to be used directly, but a common interface for the different types of fields that are supported. The usage of a field is defined by two enums at ContactDefs.h, it is a code that allow to specify additional informations for the data, for example if you want to add a phone number that is a fax you'll use this code :

...
BContactField* field = new BStringContactField(B_CONTACT_PHONE, value);
field->SetUsage(CONTACT_PHONE_FAX_WORK);
contact.AddField(field);
...

The class also accept any number of string parameters, the BFlattenable interface, and the BContactFieldVisitor interface.

BStringContactField
This is used for the major part of the fields, the value is represented as a BString object it is enough for fields like B_CONTACT_NAME, B_CONTACT_ORG...
BAddressContactField
It represent an address, allow to initialize a well-formed address via the constructor or alternatively the programmer can use the provided methods to set all the informations.

There are also other types of fields in the plans, one of these is the BCustomContactField.

Translators
As said while not supporting all fields, they can translate and exchange fields with a common format. There are some bugs, but the whole process is working as well and i consider this part of the project complete.

Services Kit
Unfortunately this side is not close to be completed, i have a draft and i'm working to get it enough complete.

At the moment the main classes are :
BServicesRoster
A simple class that allow to manage the addons in a more low-level manner...something similar to BTranslatorRoster giving access to the add-ons so nothing specific to the contacts support but a base for many uses (including contacts addons).

BServicesAddon
This will be the class specifying the API used by the addons, using a generic set of methods...version, name, friendlyname, services_addon_type, init and so more. Providing a Process() method used to receive data as BMessages from the server. In the same manner, will be instantiated with a messenger object to talk with the server.

BContactRoster,
basically store the BContacts provided in the address book. The user will instantiate an own object reading only the contacts they want. In future would be nice to see classes like BContactQuery...at the moment they will specify simple access to the fields stored in the address book. Internally will use an instance of the BServicesRoster talking with contacts addons.

I have created a git branch of the Haiku's tree at the url :

https://github.com/Barrett17/Haiku-services-branch

At the moment it is a plain copy of the tree, in the next day's i'll update the code since using the osdrawer repo was limitative.

These weeks were prolific in terms of design and experiments but due to university commitments i am a bit late with the expected goals.
At this point i have an implementation of BContact / BRawContact and i'm working to get the VCard translator functional. In these hours my focus is the communication part between the raw contacts and translators.

One of the latest design decisions was to make BRawContact own a translator that is suitable for writing the format specified by the user, otherwise it will use the default B_CONTACT_FORMAT (a flattened BMessage) for the final file. The passage of the data between the object and the translator will be done every time the programmer want via the Commit() method. If a path is not passed, the BRawContact will be virtual and stored in memory.

An example of how the api will look approximately :

	BContact contact = BContact(new BRawContact(B_VCARD_FORMAT, "/boot/home/"));
	status_t ret = contact.InitCheck();
	BContactField* field = new BContactField();
	field->Add(new BPhoneNumber(..));
        ...
        contact.AddData(field);
        ...
	ret = contact.Commit();

Most of you probably already know that one of my major inspiration sources was the Android's ContactsContract API. It is already giving some ideas, like the BContactField object. In fact they use a class named ContentValues, that is similar for some aspects to BMessage as a generic data container, i'm thinking to make a wrapper for BMessage in order to provide an object (BContactField) that makes comfortable passing data fields to BContact / BRawContact. It will help also internally, since as said a flattened BMessage is the common translation format (B_CONTACT_FORMAT).

In the immediate future i'm also planning to implement a set of functions in TranslationUtils.h able to convert a BPositionIO or a file into a BContact in a similar manner as the already existent functions for BBitmap and other formats but using the provided Contact API.

There is a new osdrawer project at http://dev.osdrawer.net/projects/contacts-kit, i'm planning to update here some code during the next days.

At this point i expect to get a first working version of both translators in 7 days, in order to begin working on the services_server part. The first goal will be getting the BContactRoster class up, then to add some functions like unique ids for translator (only BContactRoster will be able to edit the id of a BContact because the first goal of the class will be to provide a centralized management of the contacts) and then focusing on the implementation of the services add-on hosting server including an add-on API. My major idea about that is to implement it using a BMessage protocol and some basic hook functions for the services server -> add-on communication.