Meetings2011-10-06 » History » Version 18
Version 17 (S. Wrede, 10/06/2011 06:05 PM) → Version 18/21 (S. Wrede, 10/06/2011 06:08 PM)
h1. Meetings 2011-10-06
h2. Report HUMAVIPS code camp (also make notes for Stefan)
* Nao Robot
** Improved CPU
*** Increased performance (e.g. video streaming)
* Aldebaran
** Develops new open middleware
** Made a tool for building binary distributions
*** Will be open sourced within a few weeks
* High-level overview of projects currently missing
** Catalogue can solve this (at least for CITEC projects)
** Currently in beta
** What about partners?
*** Partners can use the catalogue
*** CI servers of partners could be integrated
* Experiences
** RSB mostly OK
** RST unclear
** Easy-to-use Matlab interface would be useful
h2. RST Policies and (Re-)Organization
* Add seperate directories per user or projects in Beta
* Use different name for "beta"
* Communicate that changes in "beta" are allowed and welcome
* Promotion requests as redmine issues?!?
* Use seperate libraries / redmine projects for beta part?
* Install type system in prefix
* External monitoring needed and welcome
* Connect type system to catalogue
* How to decompose domain types in protocol buffer types?
** Can language level considerations give guidance? (e.g. sending a 3DPoint as part of another object to a generic 3DPoint component)
* Consider API/ABI breaks if RST types change (what cases exist?)
* Consider naming scheme for protofiles?
* RPC service to retrieve IDL information from running components via libRST?
** One RPC service per process?
* Decisions:
** So far, we will collect the datatypes in the RST repository
** Add installation target for proto files to RST library makefiles to have the IDL defs in $prefix
** Or, if possible add introspection support for RST such that converters can report on their used IDLs
** Use $prefix/share/RST for logger to retrieve IDL specifications
h2. Default Connector Policy
h2. System-level Introspection
* Urgently needed: Informer per Participant about participant state
** Provide client-API in separate library + unix tool?
* Requirements (Motivation: Debugging)
** Presence / state information
** Type introspection
** Application-level logging (and runtime configuration)
h2. Report HUMAVIPS code camp (also make notes for Stefan)
* Nao Robot
** Improved CPU
*** Increased performance (e.g. video streaming)
* Aldebaran
** Develops new open middleware
** Made a tool for building binary distributions
*** Will be open sourced within a few weeks
* High-level overview of projects currently missing
** Catalogue can solve this (at least for CITEC projects)
** Currently in beta
** What about partners?
*** Partners can use the catalogue
*** CI servers of partners could be integrated
* Experiences
** RSB mostly OK
** RST unclear
** Easy-to-use Matlab interface would be useful
h2. RST Policies and (Re-)Organization
* Add seperate directories per user or projects in Beta
* Use different name for "beta"
* Communicate that changes in "beta" are allowed and welcome
* Promotion requests as redmine issues?!?
* Use seperate libraries / redmine projects for beta part?
* Install type system in prefix
* External monitoring needed and welcome
* Connect type system to catalogue
* How to decompose domain types in protocol buffer types?
** Can language level considerations give guidance? (e.g. sending a 3DPoint as part of another object to a generic 3DPoint component)
* Consider API/ABI breaks if RST types change (what cases exist?)
* Consider naming scheme for protofiles?
* RPC service to retrieve IDL information from running components via libRST?
** One RPC service per process?
* Decisions:
** So far, we will collect the datatypes in the RST repository
** Add installation target for proto files to RST library makefiles to have the IDL defs in $prefix
** Or, if possible add introspection support for RST such that converters can report on their used IDLs
** Use $prefix/share/RST for logger to retrieve IDL specifications
h2. Default Connector Policy
h2. System-level Introspection
* Urgently needed: Informer per Participant about participant state
** Provide client-API in separate library + unix tool?
* Requirements (Motivation: Debugging)
** Presence / state information
** Type introspection
** Application-level logging (and runtime configuration)