candycode / websocketsplus Goto Github PK

When implementing #13 do add the option to specify a minimum size for a data packet should be added to the queue regardless of the done flag.
Use case: receiving large dataset

1. send begin message
2. send unformatted byte chunks
3. send end message

The service receiving the data might decide to write to a temporary file: open file in (1), write data chunks in (2), close and possibly read in (3).

Add place where to store http cookies.

Open issue: how to handle removal of associated data after cookie expires.

Change license to LGPL and update file headers.

Currently there is no reusable class to speed up the implementation of services; the SessionService implementation is for testing purposes only and not reusable in its current form.

Do implement a minimal SessionService class that works like the one implemented in the osgcapture example.

Consider not throwing an exception when the client disconnects.

Currently whenever data cannot be sent a standard runtime_error exception is thrown, this forces client code to handle the exception from the outside.
Alternative options include:

1. create custom exception with additional details:
   • context reference
   • service references
2. invoke a Service::OnWrite error method and decide if service should be shut down depending on the return value

Currently leaning towards option 1because it's easier to let client code figure out what to do by itself without forcing Service implementations to support error handling

Currently the html code to test basic functionality is stored within comments; add files instead.

Currently only a single logging level is supported, levels are not OR-ed together.

Make 'binary' member a static value in order to select text or binary operations at compile time; alternative is to use Context to retrieve the per-session value of binary flag.

Implement HTTP service

Current example files occupy most of the repository space, remove examples and put them into separate websockets-plus repositories.

Always support fragmentation for send.
Optionally support fragmentation in receive mode: allow client code to decide if it wants to simply increase the size of the rx buffer to fit one packet or support fragmented receive.

How does this compare to Beast, which offers WebSocket and HTTP implementations?
http://vinniefalco.github.io/

Currently services implementing different protocols must all use the same Context::GetServiceData method to access data.
It is therefore not possible to have different services access different data.
Change interface by making GetServiceData dependent on the Service data type and add variadic template list to Context instead of a single service data type:

Context< Service1, Service2... >

Internally data are stored into a tuple: tuple< ArgsT::DataType > data_;

and accessed through: GetServiceData< Service1 >() -> returns reference to Service1::DataType

Calling

libwebsocket_service(context_, ms);

Does not result in a min dealy of ms milliseconds between calls, need to handle request/reply throttling manually

No need for the stream flag: simply have Service::Sending() method always return true.

The current reference implementation of Context is generic enough to be moved in a separate include file and inside the wsp namespace part of the core websocketplus implementation.