Changes between Version 8 and Version 9 of WikiStart/OngoingWork/WebService


Ignore:
Timestamp:
06/18/14 15:03:14 (5 years ago)
Author:
sylvain.joyeux
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart/OngoingWork/WebService

    v8 v9  
    3333 * '''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. 
    3434  * '''Steffen''' when all the parsers are compatible, i'm fine with that, but we still need to select a default to install. 
     35  * '''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. 
    3536 * sending via socket, websocket possible tand tested (only JSON decode on socket untested) 
    3637   * '''Sylvain''' that is independent of the JSON library used ...  
    3738 * parser can handle nested types ('''Sylvain''' what would it be used for ?) 
    3839  * '''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 
     40  * '''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)  
    3941 * needs a serializer function for types which creates (nestes) hashes 
    4042   * this can be implemented directly in typlib-ruby as generalized method using field iterators  
     
    7375* websocket preferred (I would think "REST - i.e. HTTP - preferred" '''Sylvain''') 
    7476 * '''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) 
     77 * '''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. 
    7578* JSON parser integrated (no external .js lib) 
    7679* jQuery UI looks like a nice UI lib 
     
    7881* '''Sylvain''' doing client-side rich javascript application is a pretty complex task. Who currently has the know-how among the Rock developers ?  
    7982* '''Steffen''' Using the lib above, it is not that difficult, html is text editing and js a c-like asnychonous scripting language 
     83* '''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. 
    8084 
    8185= generic interface