• marshalling formats
    • JSON
    • BSON
    • google protobufs
  • two modes of operatoins
    • request based
    • stream-based (mostly useful for reading ports to avoid the overhead of repeating requests, could be generalized to any orocos/async events)
  • custom protocol or http (REST) ?
    • REST protocol has good library support both client and server side
      • very well suited for browser-based interaction (because it is a very common pattern)
      • can easily be upgraded to a rich server (i.e. having things rendered server-side)
      • super nice library to build REST APIs (Grape) that can then be plugged into bigger frameworks if we want to do some server-side rendering (i.e. Rails, Sinatra)
    • Sockets don't need a webserver running
      • Sylvain IMO a non-issue, Ruby libraries as e.g. Rack have very good support to start thin webservers "out of the box"
      • websocket protocol implemented in browser
      • socket don't need a websocket library
      • both websockets and socket will force us to create our own request representation, parameter passing and library-side handling. HTTP-based REST libraries exist that do that all out of the box, and are handled by the browser as-is without any javascript.


  • Sylvain IMO most requests that can be made on the orocos.rb API:
    • nameservice browsing
    • task states
    • full model
    • port reading/writing
    • property reading/writing
  • in the long run, should replace the process server API (will have to think how)


  • gem Yail-ruby promising JSON parser
    • Sylvain having done a bit of research, the best JSON support out there is given by multijson - simply uses the best JSON library available on the system. If we write a generic type-to-hash support in typelib, we can use any JSON marshaller.
      • Steffen when all the parsers are compatible, i'm fine with that, but we still need to select a default to install.
      • Sylvain well, that's the point of multijson: provide a coherent API over multiple JSON parsers so that one can get the best one for the local platform.
    • sending via socket, websocket possible tand tested (only JSON decode on socket untested)
      • Sylvain that is independent of the JSON library used ...
    • parser can handle nested types (Sylvain what would it be used for ?)
      • Steffen see example below, RigidBodyState contains a lot of Vector3d typed, but there is no specific hash creation. The Types::Base::Vector3d::to_json function is automatically used. Could be all json parsers work like this though
      • Sylvain Ah ... OK. Did not understand it this way. Yes, this is how most JSON libraries work (you convert to a nested Hash and then serialize the hash)
    • needs a serializer function for types which creates (nestes) hashes
      • this can be implemented directly in typlib-ruby as generalized method using field iterators
      • example:
        class Types::Base::Vector3d
          def to_json(*a)
              'json_class'   =>,
              'data'         => [ :x => x(), :y => y(), :z => z() ]
        class Types::Base::Samples::RigidBodyState
          def to_json(*a)
              'json_class'   =>,
              'data'         => [ 
                                  :time => time, 
                                  :sourceFrame => sourceFrame, 
                                  :targetFrame => targetFrame, 
                                  :position => position,
                                  #:cov_position => cov_position,
                                  :orientation => orientation,
                                  :velocity => velocity,
                                  :angular_velocity => angular_velocity


  • websocket preferred (I would think "REST - i.e. HTTP - preferred" Sylvain)
    • Steffen actually this is a discussion push vs. poll (a socket can do both, HTTP only poll) I think for an generic interface at least a push option should be available. In case of REST we should have a look on node.js (server side javaScript including bindings to native applications, which offeres a lot of different outputs for data (like required by REST). (JS is async by default, so node.js could be a good option)
    • Sylvain not true, you can do live streaming on HTTP these days. Actually, this is how quite a lot of server-side events work (pipelining JSON over a live HTTP connection). Using into REST + streaming would make sure that we can handle broken connections easily (it would only mean re-calling the same API endpoint). Moreover, I would really stick to Ruby for server-side stuff as most of the API is Ruby and Ruby has very good web support / libraries.
  • JSON parser integrated (no external .js lib)
  • jQuery UI looks like a nice UI lib
  • Sylvain doing client-side rich javascript application is a pretty complex task. Who currently has the know-how among the Rock developers ?
  • Steffen Using the lib above, it is not that difficult, html is text editing and js a c-like asnychonous scripting language
  • Sylvain sorry, but I have to snort. BIG SNORT. C++ is just text editing. Why are we spending so many years doing robotics again ? Doing more than a proof of concept *is* difficult and has quite a learning curve. I've done some jQuery stuff for simple tasks, not easy when you are not experienced.

generic interface

  • socket, but no UI tools
Last modified 7 years ago Last modified on 06/18/14 15:03:14