wiki:WikiStart/OngoingWork/WebService

Version 8 (modified by stpl01, 5 years ago) (diff)

--

Protocol

  • 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.

requests

  • 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)

Ruby

  • 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.
    • 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
    • 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'   => self.class.name,
              'data'         => [ :x => x(), :y => y(), :z => z() ]
            }.to_json(*a)
          end
        end
        
        class Types::Base::Samples::RigidBodyState
          def to_json(*a)
            {
              'json_class'   => self.class.name,
              'data'         => [ 
                                  :time => time, 
                                  :sourceFrame => sourceFrame, 
                                  :targetFrame => targetFrame, 
                                  :position => position,
                                  #:cov_position => cov_position,
                                  :orientation => orientation,
                                  :velocity => velocity,
                                  :angular_velocity => angular_velocity
                                  ]
            }.to_json(*a)
          end
        end
        

Browser

  • 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)
  • 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

generic interface

  • socket, but no UI tools