![[Home]](/boost.png)
OOPSLA2004/Workshop -- ResultsOOPSLA2004/Workshop -- ResultsAt the OOPSLA conference in late October a few members of the Boost community met, discussed library proposals, and other topics related to Boost, C++, and C++ libraries. The following is a short synopsis of the workshop and some events before and after. It does not do complete justice to the depth os the discussion of the proposals.
This workshop was initiated by me, People/Jeff Garland, since I knew I was going to OOPSLA and felt it would be a good opportunity to bring members of the C++ community together in a discussion of C++ libraries. So, in mid-February I started a conversation with several Boosters about what kind of workshop we could hold that would be useful and solicited help in organizing.
Kevlin Henney, Nicholai Josuttis, and Jeremy Siek agreed to be a part of the organizing committee. After some discussion, we agreed on a session to provide library authors a chance for face-to-face library review and discussion. We solicited for participation, and selected 3 libraries for review. In addition, we reserved some time to discuss what libraries are missing from Boost and the standard.
The final agenda was as follows:
Materials for each library were provided in advance allowing reviewers to read and understand the library concepts prior to the workshop. During the workshop each author gave an overview of the library which was followed by a discussion of each library.
The workshop had a total of 14 participants. Unfortunately, we lost Kevlin Henney for the whole day and Jeremy Siek for part of the day due to other conference conflicts. Nonetheless, all of the sessions created lively and interesting discussion.
The following sections briefly describe the proposed libraries. Each of the library developers got feedback on their proposal from the participants as well as answering questions and clarifying issues.
Istavan Zolyomi discussed the goals of a new Concept Checking library that would extend the current Boost Concept Checking. Details of this proposal can be found at:
This library is probably best viewed as a library of metafunctions or traits rather than as a tool that's specifically aimed at concept checking.
There is a more detailed version downloadable from http://gsd.web.elte.hu/Publications/GPCE_04/introspection.pdf, which was accepted for the GPCE 2004 conference.
Arne Adams gave a brief presentation of his Reflection library that is described in the September 2004 issue of CUJ. A more recent version is available at http://www.arneadams.com/, and the documentation is available at http://www.arneadams.com/reflection_doku/index.html. This library provides a kind of compile-time reflection that can be used to enumerate data members of a class for serialization and other purposes.
Dave Abrahams gave an excellent overview of a language neutral binding (Boost.Langbinding) capability that he and Daniel Wallin are developing. Taken from the core of Boost.Python and subsequent work, the idea is to have a standard core for binding various languages. Details of this work can be found at http://www.boost-consulting.com/writing/oopsla04.html, but the PowerPoint? presentation at http://www.boost-consulting.com/writing/langbinding.ppt may be more accessible.
The final part of the workshop was an open session to discuss the wish list of libraries. While the intent was to focus on the libraries and try to prioritize a list, much of the discussion turned to various steps Boost can take to improve overall effectiveness. More details on this are below.
Doug Gregor set the context for the discussion by giving a nice outline of the committee activity for Technical Report 1 (TR1) and the opening of TR2. Doug indicated that the committee is very interested in TR2 submissions targeted at everyday users. Given the timeframe of the committee for working on TR2, Doug indicated that it would be best if proposals are received in the next 2 years, so the committee has enough time to discuss and revise them.
Before we got to looking at the library priorities, the (perhaps inevitable) discussion of how the Boost process could be improved ensued. There were several suggestions made during this discussion including:
The one idea everyone agreed was the most important was to provide new library authors with a mentor from among the current Boost developers. The role of the mentor would be to help a new author through the development process and to help make sure all of the submission steps are followed. Many of us have done this informally, but there has never been a way to request this sort of help. The Boost community needs to develop the idea more fully and will need current Boost developers to volunteer to serve as mentors.
One problem that was identified was that there is currently no way to match people with similar interests or for users to submit a request for a new library other than asking on one of the mailing lists.
There was a long discussion of the need to refactor the web content in a way that better supports library development. In particular, the group identified 3 stages of development which users should be able to easily find out about on the Boost website:
With the current web setup, it is difficult to see the ideas and needs as well as the libraries under development. Currently the only place to see the libraries under development is on the Wiki, which is unofficial and hence is not linked from the main site (except in one place). There is no direct link to this page and no organized effort to keep the libraries under development page current.
So, the overall recommendations were as follows:
The group agreed that the Wiki is a good place to record active library development. It supports updates from anyone and hence can be updated by non-Boost developers to record their activities. Note that the Wiki was initially created to serve Boost users, not developers. But, many of the participants felt the Wiki was not supporting users well, while it was frequently used to assist in various development efforts.
One of my key goals at the workshop was to try to open a discussion about which are the most important libraries missing from Boost and what we can do to encourage their development and submission. Not all participants agreed with this approach (hence diversions to other discussions). To facilitate the discussion I created a diagram try to highlight the key, missing libraries in Boost (see OOPSLA2004/Library Roadmap for details).
This initial list of missing libraries was created using 2 techniques:
The idea of the application thought experiment is simple. Pick an application and imagine the types of libraries you would like to have. So for example, some of the thought experiments included:
Example application 1: Write a CGI (computer gateway interface) server program that generates a PNG image of server load based on input from an HTML form. Some libraries that would help include an HTML streaming library, a CGI library for marshalling the CGI form data into C++ variables, a library to generate a bar chart, and one to write the chart as a PNG file.
Example application 2: Write a pair of network servers that communicate via a custom messaging protocol using XML. Missing a network programming library and a tracking library.
Another approach is to just think about the sorts of applications that are now dominating development in C++: Networked, multithreaded, multilanguage applications. These lead to a different set of needs including a networking library and a way to support cross-language bindings.
After some initial discussion the group began discussing libraries of interest. Everyone added libraries to the list or expressed interest in the libraries already on the list. At the end of the discussion each person was given 2 votes for the libraries they consider the most important for their needs.
The results of the voting were as follows:
Overall, tracing/logging was a clearly identified need. The story on XML and threading is a bit more complex.
With XML, there are already many C++ libraries that provide XML capabilities. However, during the discussion it was clear that the participants were not happy with the current implementations. In particular, integration with the standard library was regarded as weak. In addition, during the discussion it was clear that a Unicode library was probably a pre-condition to a good XML implemenation.
As for threading, there was concern that the current Boost.Thread was not sufficient. In particular, it is not as complete as other threading frameworks such as ACE (http://www.cs.wustl.edu/~schmidt/ACE.html). Another extension of current threads would be a cross-platform wrapper around process management (a process is a type of thread that has a different resource sharing model than light-weight threads). In addition, we discussed that Kevlin Henney has identified a very different approach than Boost.Threads which may be more in the spirit of generic programming and C++. Finally, there is discussion of memory model issues in the standard committee that likely need to be resolved before a threading library can be adopted successfully.
Relational database access was also cited as a key need. It is an example of the sort of library available in most other langauges (e.g., JAVA, Perl), but not in C++ (though third party libraries do exist). This deficit makes it harder for C++ programmers or tempts development teams to jump to another language so they don't have to write lots of low level database code.
Network programming including sockets is another key area of interest. Despite ongoing and long effort a socket library for Boost has not made it to the review stage.
One of the outputs of the session was a 'poster' that highlighted the results of the workshop. Actually 3 large sheets of paper, the posters gave a brief overview of Boost and described the workshop. One sheet listed the library names and the number of votes each received.
During the evening gathering, these posters were on display while conference participants roamed freely -- drinking and eating from conference-provided food and drink. Several of us stood in front of the poster and discussed the workshop results, Boost, and C++ libraries with many attendees. We asked people to add their votes to the tally and invited discussion of libraries they would like to see in C++.
A number of us had some post-workshop discussions about how to involve the larger C++ community in Boost. This might provide an avenue to get some of the more complex and difficult libraries such as sockets completed and submitted.
The Boost workshop was a highly valuable opportunity to discuss library development with other members of the Boost community face-to-face. Hopefully, some of the process improvements will result in new libraries being completed and ultimately in proposals for TR2.
[buy lipitor online] [buy lipitor] [[buy lipitor online]]
[buy fioricet online] [buy fioricet] [[buy fioricet online]]