C. Third day

The day started with a re-evaluation of the agenda and release timelines. The proposed release date for 2.0 was august 16th.

This list of topics will be covered this week:

• Documentation review
• Website review
• Real-time Logging
• Build system review
• Crash in Collect found by Markus
• Yarp transport

This list of issues will be solved before 2.0.0:

• Code size/compilation time issue
• Tool + cmake macros to create new component projects
• typegen tool to generate type kits
• gitorious migration of all orocos projects, including code generation tools
• OCL cleanup and migration to new cmake macros

These issues will be delayed after 2.0.0:

• Thread-safe property writing (allow a peer/3rd party to change a property)
• Attribute/Property resolution, ie, maybe it's easier to introduce a 'persistent' flag in properties which flags if it needs to be serialized or not. Attributes can then be removed.
• Service discovery. Sylvain manages these things in a supervision layer written in Ruby. It's not clear yet how far the C++ DeploymentComponent needs to go in this issue.
• Diagnostics service that detects thread overruns, buffer overflows etc.
• Connection browsing: ask a port to which other ports it is connected such that we can visualise that
• Deployment gui to show or create component networks
• Full Mac-OS-X and Win32 support. These will mature in the 2.0.x releases as users on these platforms test the release.

The rest of the day continued as planned on the agenda. In the morning, a new CMake build system for components, plugins and executables was created to maximize maintainability and ease-of-use of creating new Orocos software. OCL too will switch to this system. The interface (CMake macros) and logic behind it was discussed. This tool will be further developed to be ready before the 2.0 release.

In the afternoon, the documentation and website structure was discussed. We came to the conclusion that no-one only downloads the RTT. For 2.0, they will download, RTT, the infrastructure components (TaskBrowser, Deployment, Reporting, Diagnostics etc) and the tool-chain (typekit generation, component generation etc.). This will require a restructuring of the website and the documentation, to no longer be RTT-centric, but to be 'Orocos ecosystem' centric.

The documentation will contain 3 pillars:

• Getting started
  1. Download toolchain
  2. Build
  3. Run demo
• Setting up a real system
  1. Your first component
  2. Deploying it
  3. Creating a component network
• Reference documentation
  1. API
  2. Cheat-Sheet
  3. Manuals

The reference manuals will be cleaned up too, such that they suit better 'for reference' and less serve as 'first read for new users'.

During this day, the code size problem, typegen development and Yarp transport were also further polished.

It ended with a visit to 'Parc Guell' and a walk to the old city centre, where we enjoyed a well deserved tapas meal.