ecorm / cppwamp Goto Github PK

WebSocket++ could be used for this. Wrappers compatible with the Transport and TransportBuffer concepts would need to be written.

Implement call timeouts, as per the advanced spec.

Implement challenge response authentication, as per the advanced spec.

Add more tutorial examples on how to use the asynchronous client API.

Implement subscriber listing, as per the advanced spec.

Implement callee black- and whitelisting, as per the advanced spec.

Implement pattern-based subscriptions, as per the advanced spec.

Verify that the library can be used with Visual Studio 2013. Identify, if necessary, the C++11 features that would need to be worked around to support VS2013.

It's currently too easy to forget to issue an Invocation::yield from within RPC handlers. It should be changed so that the RPC handler is forced to return one of the following:

• a RESULT with optional payload and optional advanced attributes,
• an ERROR result, which could also be thrown from within the RPC handler
• a special "no result" type that explicitly indicates that the RPC already has, or will be, manually returning a result via Invocation::yield. This makes it possible for the user to return the result in a different asynchronous handler context.

A discriminated union type could be used to contain those three variants, without incurring the cost of dynamic allocation if polymorphism was used instead.

Implement pattern-based registrations, as per the advanced spec.

Implement agent identification as per the advanced spec.

Implement caller identification, as per the advanced spec.

The is currently no way for the user to supply a Details dictionary when leaving a realm, as described here in the basic spec. There should be a Client::leave overload that takes a Details dictionary of type wamp::Object.

Implement call trust levels, as per the advanced spec.

Implement partitioned subscriptions, as per the advanced spec.

Provide a transport compatible with the WAMP LongPoll Transport specification.

Consider pooling AsioBuffers instead of allocating them from the heap each time one is needed. However, if an unusually large message is sent or received rarely, that pooled buffer will needlessly waste memory. The pool should somehow be smart enough to discard such unusually large buffers.

I have considered chaining fixed-size chunks to form arbitrarily-sized buffers, but AFAICT, the msgpack-c unpacker needs the message to be completely contiguous in memory.

Add a version of the chat example program that uses the asynchronous client API.

Implement publisher exclusion, as per the advanced spec.

Implement subscriber meta events, as per the advanced spec.

Implement ticket-based authentication, as per the advanced spec.

Provide a Client API mixin that uses std::future or boost::future.

Verify that the library can be used and compiled on Mac OS X platforms.

Implement publisher identification, as per the advanced spec.

The format specifier in json.ipp, line 99 should be "%.17e".

Allows Client instances to store "sticky" option dictionaries that are always used for the same type of operation. For example, the same CALL.Options.timeout|integer option could be reused for a particular remote procedure, or for all RPCs.

Implement a TCP-over-TLS transport.

Boost.Endian will be part of Boost 1.58.0. When Boost 1.58.0 is released, we should make that the minimum required version for CppWAMP, and drop the dependency on the "external" Boost.Endian library.

Implement call cancellation, as per the advanced spec.

Implement progressive call results, for the callee, as per the advanced spec.

Callee requirements:

• HELLO.Details.roles.callee.features.progressive_call_results|bool := true
• YIELD.Options.progress|bool := true
• Receive INVOCATION.Options.receive_progress|bool := true

Note from spec:

The progressive YIELD and progressive RESULT may also be empty, e.g. when those messages are only used to signal that the procedure is still running and working, and the actual result is completely delivered in the final YIELD and RESULT

This feature does not require any special treatment for the callee.

Implement subscriber black- and whitelisting, as per the advanced spec.

Caller requirements:

• HELLO.Details.roles.caller.features.call_timeout|bool := true
• CALL.Options.timeout|integer

This feature does not require any other special treatment for the callee.

Implement feature announcement on the client, as described in the advanced spec.

Client requirements:

• HELLO.Details.roles.<role>.features

The semantics and behavior related to feature announcement are not clearly described in the spec, so I raised that issue in wamp-proto/wamp-proto#159.

If an optional "details" parameter is added to Client operations, the combination of optional parameters will result in many overloads. For example:

call(procedure, handler);
call(procedure, args, handler);
call(procedure, details, handler);
call(procedure, args, details, handler);

The above overloads could be replaced by a single fluent API:

call( Rpc("foo")
    .withArgs({42})
    .withKwArgs({{"bar",false}})
    .withBlacklist({12345678})
    .andDiscloseMe(),
    handler );

This mechanism might also be used to unify the CoroClient and CoroErrcClient APIs under the same class.

Client requirements:

• HELLO.Details.roles.callee.features.call_timeout|bool := true
• Receiving INTERRUPT messages

The feature would require significant changes to the Client and Session classes. This feature should be implemented along with #21.

The Binary conversion of JSON Strings section of the WAMP spec describes how to encode/decode byte arrays.

For MsgPack, the BIN format should be used.

wamp::Variant would have be to extended with another bound type to contain byte arrays. std::vector<uint8_t> seems like a good candidate.

Implement a RouterSession class that derives from internal::Session and implements the broker/dealer roles according to the basic spec. The RouterSession instances would share information with a common RouterRealm class.

Reading configuration parameters and providing a meta-API should be provided in separate router application classes.

Add test cases for Session operations being executed within call/event slots. For example, verify that a client app can unsubscribe from within a pub/sub event handler.

Event/call slots are always posted to the I/O service; they are never executed with the context of the WAMP message receive handler. So while I doubt there are currently are any issues, it would be good to test for them anyway.

Return Subscription and Registration objects via shared pointer, instead of making them "handle" objects that mimic the shared_ptr API.

The default RawsockMaxLength parameter (for maximum received message length) in TcpConnector::create and UdsConnector::create is currently set to 64kB. This default value was arbitrarily chosen to fit into the default socket buffer size in Linux, which is ~85kB on my system.

Should the default value instead be the maximum length of 16MB? If users have tighter memory constraints, they can always specify a different maximum receive length.

Implement partitioned registrations, as per the advanced spec.

Implement event history, as per the advanced spec.

internal::ClientInterface::roles should be inline or CPPWAMP_INLINE.

Add cases for advanced featured supported in v0.2.0. Some may not be testable if they're not supported on Crossbar, or if they're not "symmetrically" supported by CppWAMP.

Implement progressive call results, for the caller, as per the advanced spec.

When operator<<(std::ostream&, ... is used with Event, Result, and Invocation, the keyword arguments are not always displayed. This is due to args() being used in the relevant if condition, instead of kwargs().

In some situations, the user may not want the burden of having to keeping Subscription/Registration objects "alive". Topic and Procedure should provide a .permanently() option which indicates that the subscription/registration will be valid for the lifetime of the Session object. This option would also make the Session object keep its own copy of the Subscription/Registration shared objects.

If this option is used, the user has to ensure that the callbacks can be called while the Session is established.

• Add a 'details' read-only property of type wamp::Object to the Invocation class
• Event slots should take a PublicationInfo object as their first parameter, which contains the PublicationId and Details dictionary.

Implement publication trust levels, as per the advanced spec.

Implement caller exclusion, as per the advanced spec.