Blogs

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.

During the first quarter, I defined an interface language to use for creating the bindings. I had to create my own for several reasons. Probably the biggest factor was the need to know whether the target language has the right to destroy an object. Most of the target languages has some kind of automatic garbage collection; the programmer never needs to worry about whether to delete an object to free up memory. I didn't want to force programmers to worry about it when they don't normally need to. Therefore, I had to be able to mark whether an object was delete-able, so the generated bindings could delete it automatically if necessary.

I also defined preliminary bindings for a minimal test program, wrote a preliminary generator to create the bindings, and wrote the program itself (a simple application with a window which has a single button). The preliminary generator and the test program targeted Perl.

I also tried changing some data from the test program (with the interpreter running in the main thread) while in the MessageReceived method for the window (which should theoretically lock the window's thread). I was unable to make the program block, so I will need to continue testing for thread issues as I go along. Suggestions are welcome.

I in an earlier post that I would make a decision on target languages based on two criteria, popularity with the Haiku user base and ease of writing extensions. The popularity, based on a poll on the Haiku home page, is as follows:

42 51% Python
14 17% Ruby
12 14% Lua
06 07% Haskell
04 05% Perl
03 04% Scheme
02 02% Squirrel

As you can see, Python won in the popularity category, with over half the total votes and three times as many votes as the next highest language. Extension writing looks like it will be relatively easy as well. With good scores in both categories, Python will be one of the target languages. (In fact, I've already started work on them.)

I already know how to write extensions for Perl, which means it wins in the ease category. Since I did my initial tests with Perl, it will continue to be one of the target languages as I expand the number of bindings.

However, Perl scored quite low in popularity, so I would like to add another of the more popular languages as well. Ruby and Lua both scored more than 10%. If I am able to get the Python bindings working in time, I will research extensions for those two languages. Their scores were close enough that ease of writing extensions will be the deciding factor here.

Report on first-quarter goals:

- Define an interface definition language (Done)
- Define preliminary bindings for a minimal test program (Done)
- Write a preliminary generator to create the bindings (Done)
- Write the minimal test program (Done)
- Test threading issues (Will continue into the second quarter)
- Make a final choice on target languages (Done)
- Expand preliminary bindings and add new bindings (Not done)
- Write test programs for the bindings (Not done)
- Write documentation for the bindings (Not done)

My goals for the second quarter (including the ones brought forward from last quarter) are:

- Bring the Python bindings to minimal functionality
- Write a minimal Python test program
- Continue to test threading issues
- Expand preliminary bindings and add new bindings
- Write test programs for the bindings
- Write documentation for the bindings
- If there is sufficient time, select a third target language

I was busy with finals throughout the Community Bonding period, which left me with little time to work on GSoC-related tasks. I still have 3 exams left with the last one being on June 7. That's when the fun starts. For now I'm merely playing with ZFS on FreeBSD on a virtual machine. I still need to make my way through at least the ZFS On-Disk Specification. Even though the information contained in this document is not strictly required for porting ZFS to Haiku, it's a useful read nonetheless. It also makes me look like a rockstar when I open it in coffee shops.

According to my proposal, this is what comes next:

• Finish porting dependencies (libavl, libnvpair, libuutil, libumem).
• Begin writing an OpenSolaris compatibility layer. This involves studying how threads, mutexes, condition variables etc. work on Solaris and then writing wrappers that behave in a similar manner around the Haiku API.

This means approximately one week spent on porting and testing dependencies and a fair bit of time spent on learning about low-level Solaris interfaces. One week is an optimistic estimation for a port of any kind, but some of the dependencies are merely libraries that implement useful data structures. This means they might build on Haiku without major changes. I can't say anything further unless I've taken a better look at them myself. The end result of the quarter term should be an OptionalPackage that contains all the external ZFS dependencies.

June 7 is not far :)

In the community bonding period I made some brief contacts with my two mentors and did some reading of specification for UVC devices as well as the header for the current USB kit. My mentors confirmed that the EHCI interface for isochronous transfers with USB devices is not working properly and does not have a good set of tests. Neither my camera nor my mentor's camera are successfully engaged by Codycam at the moment. Fixing this fundamental connection issue is the first priority for the first quarter of the GSoC period, before moving on to working on the UVC driver.

The GSoC is organized around a northern hemisphere summer and I am still finishing off my semester at university at the moment, so coding for Haiku hasn't been a possibility. A 100 page dissertation, final reports, projects and exams unfortunately take precedent at the moment. On June 7 I will have finished most major projects and only exams will be left. Exams shouldn't be a big deal, so I should be able to start development at that point and can hopefully make up for lost time.

I'll have more to report once I've gotten my hands dirty.