Barrett's blog

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.

Unlike most students i'm not new to Haiku, i've already contributed around the Haiku community, maybe you can remember me for my work on Caya (msn plugin). Not by chance my gsoc project is somehow related to Caya (and every app that expose contacts).

The fundamental idea is to provide a core set of classes with the aim of contacts integration into the system.
The basic idea around the entire project is fairly simple in theory : The api should be easily extendable.

Originally, my idea was to provide an API for Person/People files only. The developers, which have a more large vision of the whole system, have warned me about it in discussions, providing very useful suggestions. The resulting proposal is interesting, and i hope you will enjoy it.

Services Server
The services server at the end of my work will only host add-ons, in future it will provide the necessary infrastructure to keep in sync contacts between different services (including contacts merge).

Services Addons and Contacts translators
The Services Add-ons will be used to extend the system functionalities, a contacts "provider" addon will be located here. As demonstration for the api will be created a Google Contacts addon. However, and addon will have the possibility to work as "consumer", i.e. it will only pubblish contacts in a defined manner.

The "Contacts translators", are Haiku translators used to provide independent support for different contacts files, i will create two translators : vCard and People. These translators will never used by the final programmer, in fact, this is the first brick (providing the low level functionalities) of the whole "Contacts kit".

BContact And BContactRoster
BContact is the high level class (the class will use BContactFile internally), used to store and represent the contact (and their fields) in memory. It will be more generic as possible.

BContactRoster will make use of the Services add-ons. There will be add-ons used to store the files in a specified manner, one of these addons will be the People address book, that will store contacts in /boot/home/people as People files or pubblish them depending on the user's settings.

My Community Bonding Period

I'm planning to begin research about my project around the 10th may. During this time i want to do only two things :

• Look into Haiku translators and make design/plans about them
• Design the BContact and BContactRoster classes

Since i have already a know-how about the BeAPI and Haiku's sources, fortunately there's no need to lose time into preliminary things. Instead i want to prepare all ingredients to make the programming aspect nice and without hitches, i will also talk with mentors since i understand that design is the most difficulty part of this project and i am sure the experience of the devs will be useful.