Laurent Réveillère

Spidle: a DSL approach to specifying streaming applications

Multimedia stream processing is a rapidly evolving domain which requires much software development and expects high performance. Developing a streaming application often involves low-level programming, critical memory management, and finely tuned scheduling of processing steps.To address these problems, we present a domain-specific language (DSL) named Spidle, for specifying streaming applications. Spidle offers high-level and declarative constructs; compared to general-purpose languages (GPL), it improves robustness by enabling a variety of verifications to be performed.To assess the expressiveness of Spidle in practice, we have used it to specify a number of standardized and special-purpose streaming applications. These specifications are up to 2 times smaller than equivalent programs written in a GPL such as C.We have implemented a compiler for Spidle. Preliminary results show that compiled Spidle programs are roughly as efficient as the compiled, equivalent C programs.

Got issues? Who cares about it? A large scale investigation of issue trackers from GitHub

Feedback from software users constitutes a vital part in the evolution of software projects. By filing issue reports, users help identify and fix bugs, document software code, and enhance the software via feature requests. Many studies have explored issue reports, proposed approaches to enable the submission of higher-quality reports, and presented techniques to sort, categorize and leverage issues for software engineering needs. Who, however, cares about filing issues? What kind of issues are reported in issue trackers? What kind of correlation exist between issue reporting and the success of software projects? In this study, we address the need for answering such questions by performing an empirical study on a hundred thousands of open source projects. After filtering relevant trackers, the study used about 20,000 projects. We investigate and answer various research questions on the popularity and impact of issue trackers.

Empirical Evaluation of Bug Linking

To collect software bugs found by users, development teams often set up bug trackers using systems such as Bugzilla. Developers would then fix some of the bugs and commit corresponding code changes into version control systems such as svn or git. Unfortunately, the links between bug reports and code changes are missing for many software projects as the bug tracking and version control systems are often maintained separately. Yet, linking bug reports to fix commits is important as it could shed light into the nature of bug fixing processes and expose patterns in software management. Bug linking solutions, such as ReLink, have been proposed. The demonstration of their effectiveness however faces a number of issues, including a reliability issue with their ground truth datasets as well as the extent of their measurements. We propose in this study a benchmark for evaluating bug linking solutions. This benchmark includes a dataset of about 12,000 bug links from 10 programs. These true links between bug reports and their fixes have been provided during bug fixing processes. We designed a number of research questions, to assess both quantitatively and qualitatively the effectiveness of a bug linking tool. Finally, we apply this benchmark on ReLink to report the strengths and limitations of this bug linking tool.

Starlink: Runtime Interoperability between Heterogeneous Middleware Protocols

Interoperability remains a challenging and growing problem within distributed systems. A range of heterogeneous network and middleware protocols which cannot interact with one another are now widely used, for example, the set of remote method invocation protocols, and the set of service discovery protocols. In environments where systems and services are composed dynamically, e.g. pervasive computing and systems-of-systems, the protocols used by two systems wishing to interact is unknown until runtime and hence interoperability cannot be guaranteed. In such situations, dynamic solutions are required to identify the differences between heterogeneous protocols and generate middleware connectors (or bridges) that will allow the systems to inter operate. In this paper, we present the Starlink middleware, a general framework into which runtime generated interoperability logic (in the form of higher level models) can be deployed to connect two heterogeneous protocols. For this, it provides: i) an abstract representation of network messages with a corresponding generic parser and composer, ii) an engine to execute coloured automata that represent the required interoperability behaviour between protocols, and iii) translation logic to describe the exchange of message content from one protocol to another. We show through case-study based evaluation that Starlink can bridge heterogeneous protocol types. Starlink is also compared against base-line protocol benchmarks to show that acceptable performance can still be achieved in spite of the high-level nature of the solution.

Automatic generation of network protocol gateways

The emergence of networked devices in the home has made it possible to develop applications that control a variety of household functions. However, current devices communicate via a multitude of incompatible protocols, and thus gateways are needed to translate between them. Gateway construction, however, requires an intimate knowledge of the relevant protocols and a substantial understanding of low-level network programming, which can be a challenge for many application programmers. This paper presents a generative approach to gateway construction, z2z, based on a domain-specific language for describing protocol behaviors, message structures, and the gateway logic. Z2z includes a compiler that checks essential correctness properties and produces efficient code. We have used z2z to develop a number of gateways, including SIP to RTSP, SLP to UPnP, and SMTP to SMTP via HTTP, involving a range of issues common to protocols used in the home. Our evaluation of these gateways shows that z2z enables communication between incompatible devices without increasing the overall resource usage or response time.

Language Technology for Internet-Telephony Service Creation

Telephony is evolving at a frantic pace, critically relying on the development of services to offer a host of new functionalities. However, programming Internet telephony services requires an intimate knowledge of a variety of protocols and technologies, which can be a challenge for many programmers. Furthermore, because telephony is a resource heavily relied on, programmability of telephony platforms should not compromise their robustness. This paper presents an approach to creating telephony services that builds on programming language technology (i.e., language design and implementation, language semantics, and program analysis). We have developed a language, named Session Processing Language (SPL), that offers domain-specific constructs, abstracting over the intricacies of the underlying technologies. By design, SPL guarantees critical properties that cannot be verified in general-purpose languages. SPL relies on a Service Logic Execution Environment for SIP (SIP-SLEE) that introduces a design framework for service development based around the notion of session. SPL and SIP-SLEE have been implemented and they are now being used to develop and deploy real services, demonstrating the practical benefits of our approach.

A DSL approach to improve productivity and safety in device drivers development

Although new peripheral devices are emerging at a frantic pace and require the fast release of drivers, little progress has been made to improve the development of such device drivers. Too often, this development consists of decoding hardware intricacies, based on inaccurate documentation. Then, assembly-level operations need to be used to interact with the device. These low-level operations reduce the readability of the driver and prevent safety properties from being checked. This paper presents an approach based on domain-specific languages (DSLs) to overcome these problems. We define a language, named Devil (DEVice Interaction Language), dedicated to defining the basic communication with a device. Unlike a general-purpose language, Devil allows a description to be checked for consistency. This not only improves the safety of the interaction with the device but also uncovers bugs early in the development process. To asses our approach, we have shown that Devil is expressive enough to specify a large number of devices. To evaluate productivity and safety improvements over traditional development in C, we report an experiment based on mutation testing.

Bridging the interoperability gap: overcoming combined application and middleware heterogeneity

Interoperability remains a significant challenge in todays distributed systems; it is necessary to quickly compose and connect (often at runtime) previously developed and deployed systems in order to build more complex systems of systems. However, such systems are characterized by heterogeneity at both the application and middleware-level, where application differences are seen in terms of incompatible interface signatures and data content, and at the middleware level in terms of heterogeneous communication protocols. Consider a Flickr client implemented upon the XML-RPC protocol being composed with Picasas Service; here, the Flickr and Picasa APIs differ significantly, and the underlying communication protocols are different. A number of ad-hoc solutions exist to resolve differences at either distinct level, e.g., data translation technologies, service choreography tools, or protocol bridges; however, we argue that middleware solutions to interoperability should support developers in addressing these challenges using a unified framework. For this purpose we present the Starlink framework, which allows an interoperability solution to be specified using domain specific languages that are then used to generate the necessary executable software to enable runtime interoperability. We demonstrate the effectiveness of Starlink using an application case-study and show that it successfully resolves combined application and middleware heterogeneity.

Bridging the gap between legacy services and web services

Web Services is an increasingly used instantiation of Service-Oriented Architectures (SOA) that relies on standard Internet protocols to produce services that are highly interoperable. Other types of services, relying on legacy application layer protocols, however, cannot be composed directly. A promising solution is to implement wrappers to translate between the application layer protocols and the WS protocol. Doing so manually, however, requires a high level of expertise, in the relevant application layer protocols, in low-level network and system programming, and in the Web Service paradigm itself. In this paper, we introduce a generative language based approach for constructing wrappers to facilitate the migration of legacy service functionalities to Web Services. To this end, we have designed the Janus domain-specific language, which provides developers with a high-level way to describe the operations that are required to encapsulate legacy service functionalities. We have successfully used Janus to develop a number of wrappers, including wrappers for IMAP and SMTP servers, for a RTSP-compliant media server and for UPnP service discovery. Preliminary experiments show that Janus-based WS wrappers have performance comparable to manually written wrappers.

Improving driver robustness: an evaluation of the Devil approach

To keep up with the frantic pace at which devices come out, drivers need to be quickly developed, debugged and tested. We have recently introduced a new approach to improve driver robustness based on an Interface Definition Language, named Devil. Devil allows a high-level definition of the communication of a device. A computer automatically checks the consistency of a Devil specification and generates stubs that include run-time checks. We use mutation analysis to evaluate the improvement in driver robustness offered by Devil. To do so, we have injected programming errors using mutation analyses into Devil based Linux drivers and the original C drivers. We assess how early errors can be caught in the development process, by measuring whether errors are detected either at compile time or at run time. The results of our experiments on the IDE Linux disk driver show that nearly 3 times more errors are detected in the Devil driver than in the original C driver.