LWN.net Weekly Edition for June 4, 2015

Refactoring Roundcube

The Roundcube web-based email client has been around for nearly ten years now. Over that time, it has become quite popular, but it has built up a fair amount of technical debt that the project would like to erase. To that end, it has started a crowdfunding drive targeted at rearchitecting the code with a relatively modest goal (at least compared to the sums collected by some projects). But there's more to it than that; the project is making a real effort to widen its community by bringing in more participants—for both code and ideas.

Thomas Brüderli started Roundcube in 2005 as an alternative to the SquirrelMail and Horde Internet Messaging Program (IMP) webmail clients, which were showing their age. By 2009, though, Brüderli didn't have much free time to contribute to the project. The Kolab groupware project wanted to adopt Roundcube as its email client and he was contacted by Kolab project member Georg Greve, who was in the process of starting Kolab Systems to support Kolab. Those discussions led to Kolab Systems helping to fund Roundcube development, which allowed Brüderli and others to implement a wide variety of new features for Roundcube—all of which were released as free software.

As Greve noted in a blog about the Roundcube Next crowdfunding effort, the collaboration between Roundcube and Kolab Systems has worked well. Roundcube has been "a great success", but this hasn't translated to a larger development community:

Back in September, Brüderli put together a description of the changes that were needed for Roundcube Next. Many of the technical decisions made when the project was young need rethinking, he said. The architecture of Roundcube comes from a different era of the web "when browsers weren’t as capable and performant as they are today and when the term AJAX has not yet been known nor did we have nifty libraries such a jQuery or Backbone.js at hand".

To start with, Brüderli said, Roundcube should do more in JavaScript on the client side, rather than generating HTML pages in PHP on the server that get loaded into an iframe. A widget-based user interface based on Backbone.js should be created that would take into account mobile and high-DPI devices; it should allow customization (i.e. "skinning") through CSS exclusively. Beyond that, the project would "use more 3rd party libraries like require.js, moment.js, jQuery or PHPMailer, Monolog or Doctrine ORM". The kinds of changes he described may "sound like a buzzword bingo from a web developers conference", but they are important changes moving forward.

The Indiegogo crowdfunding campaign started at the beginning of May with a goal of $80,000; as of this writing, it has gotten a little over $31,000 with another month to run. The campaign provides the usual perks—stickers and T-shirts, for instance—but it also provides ways for larger donors to get more involved with the project, especially during the refactoring and rearchitecting that embodies Roundcube Next. For example, donations of $75 or more get access to the "backstage pass":

Donations of more than $5,000 add the "advisor" perk, which gives a seat on the Roundcube Advisory Committee; so far, two donations of that amount or more have been pledged (in fact, one is at the $10,000 "deployer" level that adds ten hours of consulting with the Roundcube team). The campaign is of the "all or nothing" variety (also known as "Fixed Funding"), which means that if it doesn't reach the $80,000 goal, the funds will be returned to the donors. It is hard to say for sure, but the pace of contributions suggests that the campaign may struggle to reach the goal, which is both somewhat surprising and sad.

That would not stop the efforts by Kolab Systems to push the project forward, though it would likely slow progress somewhat. As Greve noted in his post, a community-wide effort is much more desirable:

Perhaps there are other up-and-coming projects that are garnering more attention than Roundcube; Brüderli mentioned RainLoop and Mailpile (which we looked at back in September) in his post. Both of those may offer compelling user interfaces, "which make Roundcube look like the old dinosaur", but they lag behind the feature set of Roundcube. It's also not clear that either of those projects is having any better success at attracting a community for what should be an important component of a free and open internet.

Even if the campaign were to fail (and, given the amount of money targeted, that is a bit hard to understand), it would be nice to at least see more of a community spring up around the project. It is, evidently, quite popular with various webmail providers, but apparently falls short in gaining contributions and suggestions from those users. Perhaps the campaign can serve as a wakeup call of sorts to help build a Roundcube community—both for the Next project and for the future beyond that. Unlike some other fundraising campaigns, the Roundcube Next campaign would seem to be as much as about raising a community as it is about raising money.

Comments (11 posted)

Ambient light adjustment on the desktop

Many current smartphones and tablets are able to automatically adjust their screen brightness in response to ambient lighting conditions. Doing so is often to help reduce battery usage, but it also provides a more eye-pleasing (or, to put it another way, a less eye-straining) user experience. Both issues are of concern to laptop users as well, but desktop Linux environments have not historically supported such a feature. Recently, Richard Hughes released a small, inexpensive hardware add-on that make automatic backlight adjustment possible.

The device is called the ColorHug ALS (for "ambient light sensor"). Hughes announced it in March 2015, with an initial batch of just 42 units. The ALS uses the same light sensor that Hughes has previously employed in his first-generation ColorHug devices. Around the same time, he announced the first test units of a significant update to the ColorHug that makes use of a more sophisticated light sensor. Consequently, the ColorHug ALS may be, in part, a way to make use of unused stock from the old model—in which case it is possible that, when the first batch is gone, a second batch may never appear (although the designs and schematics are freely available to anyone wishing to make their own).

On the other hand, the ColorHug ALS is used with the same client software package (colorhug-client) as the ColorHug colorimeter, which could perhaps be repurposed as an ambient light sensor should the user be so inclined. Hardware details aside, though, it is the software side of the project that is the most interesting. The device is physically tiny; it plugs into a USB-A port and less than half of the circuit board sticks out beyond the edge of the port—just enough for the light sensor and a status LED that blinks when inserted.

Version 0.2.6 and newer of colorhug-client includes a tool called colorhug-backlight that polls the device for an ambient-light reading, then adjusts the display backlight setting in order to compensate for any changes since the last measurement. The user needs to manually adjust the brightness to their personal preference; the utility just makes adjustments to keep it at the same relative level as conditions change. The tool also provides a time-series plot of the readings over the past few minutes, should one desire to see some context.

I tested out the device and tool on a laptop (running GNOME 3.14, which is the minimum required version, although I did have to manually update the colord and gusb packages to the versions that were included on the USB stick that shipped with the device). Under normal conditions, the brightness adjustments are subtle enough that one might not even notice them happening. A sudden, drastic change might make for a different experience, of course. Users whose computing environments include strobe lights might find the device's response time less satisfactory, but those users clearly have bigger issues to worry about.

Moving forward, though, requiring the installation and usage of a custom utility to maintain proper backlight levels is hardly the ideal solution. To that end, Hughes noted in his original blog post that the goal was to get the backlight-control framework moved upstream into GNOME control center.

The next big improvement on that front came on May 27, when he announced a new version of the ALS firmware. This firmware revision is the work of Benjamin Tissoires, and it implements the Sensor Human Interface Device (HID) API that Microsoft is promoting to Windows 8 equipment manufacturers. Consequently, the same code (presumably GNOME control center, at some reasonably near point in the future) would be able to monitor the ColorHug ALS or the built-in light sensors of many recent laptops. Thus, a great many more users will be able to take advantage of automatic brightness adjustments.

Users on desktop machines, though, appear to be out of luck for the time being. Obviously battery life is not of concern to anyone running on wall power, but lighting conditions can and do change in offices and homes as well. Unfortunately, external displays do not provide the same sort of access to backlight adjustments that laptop screens do—so, even with an ambient light reading, other steps would be required to keep the brightness level consistent. Hughes noted this in an email to the colorhug-users mailing list. In a follow-up message, he added that supporting external monitors under X11 would require "several hundred hours" of additional work. The task would be far simpler under Wayland, he said, but at present there are not enough Wayland-only systems to justify the effort.

On May 22, Bastien Nocera announced the 1.0 release of his iio-sensor-proxy project, which provides a general framework for monitoring a variety of environmental sensors (as distinct from internal hardware health sensors like CPU thermometers, which have been well-supported on Linux systems for quite some time). Ambient light sensors are among the first sensors supported by iio-sensor-proxy, and Nocera's announcement included a preview image of how the support may look in GNOME 3.18: a simple toggle switch labeled "Automatic brightness" underneath the existing screen-brightness slider.

Widespread support for this sort of feature may someday be taken for granted. Until then, the ColorHug ALS remains an inexpensive (£20) and simple way to keep one's screen brightness even. It will be interesting to see how much further the project can go, though: the light sensor in the ColorHug ALS reports RGB color readings as well as overall luminosity; one could conceivably use it to make adjustments that take the color of the room light into account as well. There have been allusions to such uses on the colorhug-users mailing list; suffice it to say that a number of people are interested in having their Linux distribution respond more readily to the real-world conditions surrounding the user—which is always a positive step.

Comments (11 posted)

V2X networking and Linux

Despite the prominence that Linux plays in automotive consortia like GENIVI and the long list of car-industry heavyweights involved in projects like Automotive Grade Linux, there are still plenty of areas in the automotive market where Linux and open-source software are forced to play catch-up. One of these areas is so-called V2X networking—a blanket term that encapsulates a handful of related initiatives, namely vehicle-to-vehicle (V2V) communication and vehicle-to-infrastructure (V2I) communication. At the 2015 Automotive Linux Summit in Tokyo, Hong-Jong Jeong from ZENOME gave a talk on the basics of current V2X networking projects and some insights into how Linux developers can get started.

The main barrier to participating in V2X development, he explained, is that the companies spearheading the work have only released hardware in "black box" form: proprietary, undocumented radio modules, often in sealed enclosures. The literal black-box approach makes developing device drivers virtually impossible, of course, and it does not help that the devices themselves tend to be prohibitively expensive as well.

Nevertheless, there is published standards work to draw on, and progress is being made. ZENOME has been concentrating its efforts on V2V. As of today, there are three main standards in use for V2V networking that are designed to function together, and they are close to final approval in the US and in Europe. The lowest layer is 802.11p, an extension to the existing WiFi standard. On top of this is the IEEE 1609 family, which defines a multi-layer stack for the Wireless Access in Vehicular Environments (WAVE) architecture. Finally, the top level is defined in SAE J2735, the Dedicated Short Range Communications (DSRC) Message Set Dictionary.

Broadly speaking, the standards fit together as follows. V2V exchanges are, due to the nature of moving vehicles, short and transient. So 802.11p sets out some exceptions to the normal 802.11 WiFi physical and access-control layers: links between vehicles take place Outside the Context of a BSS (basic service set), so they are referred to as "OCB." A BSS would be the network defined by an access point or the ad-hoc network created in WiFi ad-hoc mode; these conventions are not established between vehicles. There are no authentication or association steps at the access-control level: all participants transmit a wildcard BSSID. At the physical layer, 802.11p standard defines seven 10MHz-wide channels in the 5.9GHz range for V2V networking, with two reserved for emergency and safety messages.

At the level above 802.11p, the WAVE specification defines a connectionless, UDP-like message protocol. The header includes a service provider field, but no IP address, since the participants may have no Internet gateway at all. The top of the stack is the DSRC Message Set, which defines a set of well-known messages that vehicles may transmit and are expected to understand. Jeong discussed several of the messages, which include emergency vehicle alerts, road-side incident alerts, and map data. The most common message type, however, is the "basic safety message," which is a general status report vehicles are expected to emit periodically.

As far as Linux support is concerned, Jeong noted that, as of 3.19, there is an OCB mode patch for 802.11p in the mainline kernel. A team at the Czech Technical University in Prague and developers at Volkswagen have written patches adding the necessary support to mac80211, cfg80211, and iw. With those patches, he said, it is possible to implement raw socket support.

Acquiring a radio device capable of transmitting or receiving 802.11p has been more difficult. Through some trial and error, ZENOME has found two 802.11a chipsets with open-source drivers that can be modified to work with 802.11p's narrower channels. Both are mini-PCIe cards from Atheros, and the company has been testing them with the Ventana GW5100 Single Board Computer from Gateworks.

Using that hardware and software combination, it is possible to set up a machine that captures WAVE packets and decodes DRSC messages. ZENOME maintains a Yocto layer called meta-v2x with the configuration to receive WAVE packets and hand them up to an (included) user-space daemon that decodes the DSRC message content. At the moment, he emphasized, it is still a work in progress. But the team has tested it against four models of V2V black-box radio from the two leading manufacturers, capturing traffic with tcpdump and Wireshark.

The next steps that the team is exploring include a kernel-space module for handling WAVE messages, a priority queue (which would sort incoming messages based on their emergency status), and some sort of API for applications.

So there is clearly quite a way to go. Even with ZENOME's work, it is only possible to receive V2V messages, and only on two specific hardware devices. Transmitting V2V is yet to come, as is V2I networking and further V2X ideas—Jeong mentioned one recent addition to the V2X fold: V2P networking, for vehicle-to-pedestrian messaging. There is a lot of interest in these networking systems, both from the "intelligent road infrastructure" side, which envisions signs and highway markers that constantly update passersby about nearby conditions, and from the autonomous-vehicle side, which is focused on safety and collision avoidance.

It is, perhaps, unfortunate that the Linux community is forced to hack together compatible radios from other networking equipment, but if experience teaches anything, it is that Linux will always catch up if the need is real enough. Given the time and resources being poured into automotive Linux efforts at present, it is probably only a matter of time before our favorite operating system is on par with the proprietary V2X vendors' products.

[The author would like to thank the Linux Foundation for travel assistance to attend ALS 2015.]

Comments (none posted)