Blogs

As part of the Google Summer of Code I'll be working on developing a driver for Haiku that allows for the use of high-end webcams. By high-end webcams I mean in this case those which adhere to the USB video device class (UVC) specification. Preliminary work will involve bringing Haiku's support for the Enhanced Host Controller Interface (EHCI) to a point where UVC driver development proper can begin. Understanding the state of EHCI support and what work needs to be done in order to begin UVC development is my major goal for the community bonding period.

UVC development will entail the detection and exposure of camera features via Haiku's media kit. This will require (if I understand correctly) the production of a node with an attendant ParameterWeb which will hold the actual feature definitions. Then ideally any interested application will be able to issue commands to a UVC compliant camera and receive back appropriate responses in the form of image frames or video streams in various formats and resolutions, or status reports depending on the camera. The primary test camera will be a Logitech Quickcam Pro 9000 which supports a fairly wide range of resolutions, contains a microphone, and has a hardware button (presumably for taking still photographs). I have also noticed during the course of some computer vision research with the camera that it has what appears to be a hardware driven exposure compensation feature. There is also a similar feature exposed through the Windows Logitech driver software, but when this is turned off some exposure compensation still occurs. It will be intersting to see whether this feature is genuinely rooted in the hardware or is a result of hidden propietary Logitech software.

Hello. I'm Mike and I'll be porting part of the VirtualBox guest additions to Haiku. My full proposal is here, but briefly, the features I plan to port include:

• Mouse pointer integration
• Shared folders
• Shared clipboard
• Time synchronization
• An improved video driver
• Guest control (executing commands on the guest from the host)
• Guest properties

During the community bonding period I plan to spend a bit of time reading more code and discussing with the developers to learn more about how things work in both Haiku and VirtualBox. I also plan to play with mmu_man's patch to get it to work with the latest versions of VirtualBox and Haiku so that I have a working base to start from when the coding period starts.

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.

My project will expose the Haiku API to scripting languages. During GSoC, I will focus on enabling the creation of GUI apps; this will include large parts of the Interface Kit and some essential classes from the Application Kit. I will target Perl and Python as the scripting languages.

(After GSoC, I would like to support other languages as well, and increase the number of classes available from scripting languages.)

A timeline is available by following this link.

During the bonding period, I will be looking at the Python API, with a view to developing a generator to create the code for these extensions from an abstraction language, as an alternative to using SWIG. (I will not make a final decision on whether to use SWIG until I have determined whether it is feasible to use a custom-built generator within the GSoC time frame.)