Services Kit

What Will Happen....

Blog post by Barrett on Sun, 2011-09-04 02:23
, ,

You probably know that i have not passed the GSoC final evaluation. Although i am a bit discouraged (it's natural i think), as said from the begin, it's not my intention to abandon my project. Money wasn't my first motivation to work, and it will not be in any case.

It's just a short post to tell you what is the state of my code, and about which i'm working on.

At the end of gsoc, contacts kit's base classes are working fine, People were refactored to use my contact API, so i'm writing here my goals for the next period (deadline is presumably before january) :

* Move attribute indexing from People to the PeopleTranslator.
* Adjust file changes monitoring in People.
* Add a PeopleFilePanel class to export contacts into formats different than Person format.
* Fix all TODO and my late mentor's suggestions

* Create BContactList and BContactFieldList classes to make basic operations on collections of objects...like merging of contacts.
* Finalize BContactGroup by using the mentioned classes.
* Create the BContactRoster class, and make working the BAddressBook class (that will wrap /boot/home/people).
* Integrate Mail with BAddressBook.

Sorry for few details, my first need was to notice you that i'm already working on the project.

Below some screenshots about my latest gsoc work :

http://imageshack.us/f/856/screenshot2kz.png/
http://imageshack.us/photo/my-images/853/screenshot2km.png/

Contacts Kit, Mid-term

Blog post by Barrett on Tue, 2011-07-19 17:16
, , ,

From my latest post, i had to do more work on the base classes, i realized that my implementation of BContactField was too inflexible for the use so my progresses were not fast as i hoped.
The main problem was to provide something that can fit the simplicity of the Person format (people files) and the complexity of VCard. The result was BContactField. Starting from a number of fields (defined in ContactDefs.h) the class provide some methods to access the field-type of a particular fields and give an interface able to manage properties and parameters as well. At the bottom there are some classes that implements BContactField, they will be used directly by the user, let me give some examples :

BStringContactField
This merge every fields that does not have any other object or special functionalities like B_CONTACT_NAME or B_CONTACT_EMAIL.

BUrlContactField
This is the first example of a field that will incorporate an object from the Haiku's API, in this case it's simple but will be helpful when the BAddressContactField will be added.

How the API help to distinguish between the type of the fields?

You can use the method BContactField::FieldType() but there's a more simple solution, using the visitor pattern i have created a BContactFieldVisitor class, it is nothing more than an interface that specify one Visit() method for every BContactField child class. Implementing a your own class, when you receive a BContactField you can pass your visitor into the BContactField::Accept() method without having any troubles converting the base class to the derived class. One pratical use is for example the EqualityVisitor that allow to implement the method BContactField::IsEqual() in a nice manner. Also the VCardTranslator use a private visitor as a class that convert every field into a VCard string.

While i should commit some changes for BContactField, BContact and BRawContact are basically complete and usable and seems working as well.

Translators

The state of translators is summarily good, at the moment VCard can read and write some basic properties, People is in full development state. The main problem with it was a intrinsic limitation of the translation kit, basically you have to pass a BPositionIO (BFile, BMemoryIO..) to a translator but people files are recorded as attributes. You cannot edit an attribute using a BPositionIO since they are data written outside the file, so at the moment the translator will check if the input/output (as the case) is a BFile and if not it will fail.

Future
At this point i will not make forecasts, i'm working on a plan for the services kit and the addon API in order to begin discuss it with my mentor(s), the first part of the project seems close to be complete so i'll update you with a blog post in the next days.

Contacts Kit, Quarter-term

Blog post by Barrett on Tue, 2011-06-14 22:46
, , ,

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.

Contacts Kit, Community Bonding Period

Blog post by Barrett on Mon, 2011-05-30 11:17
, , ,

During the community bonding period, i have researched around the project to prepare my work for the coding days that will follow.
I also promised to talk with the other devs in the ml, it was not necessary in these days...i'm working with the help of Alex to a document describing the entire API in order to discuss it in the ml.

The first problem was to choose a Default Media Format for contact translators, my choice has been addressed to a flattened BMessage. BMessage will be used internally by BContact to represent the contact fields and the state of the object. BContact will be also a BArchivable object.

All that could look strange for a naive, but there are some aspects that should not be underestimated :

  1. Easily sendable through applications and network (useful in future when sync support will come)
  2. Make simple to save the state of an object on a disk and then restore it at the next boot

So one of the most important aspects of BMessage is their flexibility in storing informations. The contact kit will define a set of fields used to represent a generic contact in memory, but it's too restrictive! Apps and addons should be able to define custom types of fields since the API cannot in any case define a set of fields generic enough to support every existent and future API. This is already an obscure side for me and i need some hours to make clarity and choose the best solution.

Portable Contacts

Portable Contacts is REST API using OAuth with the aim to provide a generic access to contacts from different services, at the moment it support many services like the OpenSocial platform. Who has read my proposal probably remember something about a "Google Contacts Services Add-On". I have decided to switch it into a "Portable Contacts Addon". For more informations : http://portablecontacts.net/.

Goals For the first quarter

  • A little patch for the translation kit to support the Contacts translators
  • Basic BContact Implementation
  • vCard and People translators

Services Kit features overview

Blog post by Shisui on Thu, 2010-08-19 09:45
, , , , , ,

The coding period of the Google Summer of Code is now over since this Monday, and it's time to give to the Haiku Community a debrief of what has been done on my initial project, what has been modified, and what remains to do.

Services Kit is Going Well

Blog post by Shisui on Sun, 2010-07-11 20:02
, , , ,

It's been a month and half since the very beginning of the GSoC coding period, and this is my first blog post about Services Kit. In fact, it's quite difficult to write interesting things for both developers and non-developers, I waited to have some materials before writing a report of my work and ... it's time !

If you manage to build complex applications over the original BeOS Network Kit, you will quickly face a major problem. Indeed, if it's a good C++ wrapper of the BSD sockets API, it's only a wrapper, providing useful classes to handle a network link, but no more. Services Kit is here to provide a more complete set of useful classes which will let developers to get rid of internet protocols and to only think of the good part of a web service client application.

Syndicate content