This is a blog post preserved for historical purposes.
This blog post is presented as it was written by the original author, and may not include updates following changes in Haiku later versions. Up to date information is maintained in the "daily tasks" guide. With the advent of package management and hrev46391, it has become possible to prevent a package from being extracted at boot time. From a suggestion of Matt, and with the contribution of Luroh (thanks!
Hello, it has been passed some time from the Part 1 of this article, I’ve continued my investigations as well, and I have finally some more clear plans for such a hypotetic Jack2 port. Unfortunately i had not enough time to research a bit more in the latency differences between the media_kit and jack, sorry, this should be post-poned until i have precise emphyrical measuring methods.
To better understand this article i suggest you to read the first part.
Intro
In the last year i managed to play a bit more with the Haiku media_kit. It was already discussed in various places if jack2 should be adopted, ported, or someway integrated into Haiku. There are various opinions out there, and more or less going down into the topic i want to show you what i think about.
Jack2 is a real-time audio server for UNIX systems, to be more specifical a smp focused reimplementation of Jack (which is single-threaded), it provides a protocol used by audio apps for inter-communication.
In some situations, for example when we are using linux, can be extremely annoying to reboot into Haiku every time we need something (for example when we have a ppp connection).
I’ve written this article and i decided to post it here, in the hope that will help users and developers to have the life a bit simple.
There’s a fast method to boot a physical Haiku partition using VirtualBox, it require only a few commands.
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.
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.
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.
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.
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.
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.
