template<typename IStream, typename OStream, typename Serializer = MsgPackSerializer> class session { |
void publish(const std::string& topic, const anyvec& args, const anymap& kwargs);
template <typename TArgs, typename TKwargs>void publish(const std::string& topic, const TArgs& args, const TKwargs& kwargs);
In fact, the user API should not expose details such as the
serialization used at the transport level. The serialization is
negotiated for WebSocket (and also RawSocket in the latest revision).
Yes, the current API is what I'd call well designed, and we as said
above, we don't want to couple user code to details such as
serialization. Also, since WAMP is dynamically typed, the use of an IDL
to generate statically typed, rigid structures does not fit.
> the way payloads are exchanged needs to be revised, which might break
> the current API.
No, it doesn't. We can implement JSON serialization without changing the
API. If you want to follow that road, that would be of course a welcome
additition! But binding user code to implementation details is a no go
(as far as merging is meant of course .. you can fork and do whatever
you like obviously).
template <typename TArgs, typename TKwargs>
void publish(const std::string& topic, const TArgs& args, const TKwargs& kwargs);
Payload p = {"John", 42, true};session.publish("new employee", p);
Both of above libs seem to follow the IDL / code generation road, which
does not fit WAMP.
Just some short note as I am on mobile: I am ready to have a fresh look at all of this, and should we come up with something significantly better, we can even break user API. The hard part probably isnt the outgoing leg, but the incoming. Eg with registering procedures, how to transform the dynamically typed incoming call result into a static type, how to tell the lib that desired static type and how to handle situations where the incoming value cannot be transformed into the former ..
Sent from Mobile (Google Nexus 5)
--
You received this message because you are subscribed to the Google Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autobahnws+...@googlegroups.com.
To post to this group, send email to autob...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autobahnws/d1e2747e-043e-4c99-af13-07506d97102c%40googlegroups.com.
Ah, right. A SAX level approach like https://github.com/miloyip/rapidjson/blob/master/example/simplereader/simplereader.cpp for transforming incoming WAMP JSON payloads to boost::any might work
Sent from Mobile (Google Nexus 5)
--
You received this message because you are subscribed to the Google Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autobahnws+...@googlegroups.com.
To post to this group, send email to autob...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autobahnws/7e95c604-fac9-413d-8f72-0d45567a78bc%40googlegroups.com.
The hard part probably isnt the outgoing leg, but the incoming. Eg with registering procedures, how to transform the dynamically typed incoming call result into a static type, how to tell the lib that desired static type and how to handle situations where the incoming value cannot be transformed into the former .
> <mailto:autobahnws+unsub...@googlegroups.com>.