<feature> Lower-level, non event-based APIs too

[Theldus]

Description

In issue #24, was discussed the possibility of having a low-level API for finer control over wsServer.

This is a much-desired feature: while the current API provides a clean and intuitive way on how to use web sockets, it hides many implementation details, such as the dynamic memory allocations that occur under the hood.

A lower-level, non-event-based approach becomes interesting for using wsServer in embedded systems, where memory usage and OS resources are scarce.

Additional routines like the ones described below might be interesting in this scenario:

• ws_listen: create the socket and let the server listen on a port

• ws_accept: equivalent to accept. Accepts a single connection and performs the handshake. From this point on, it becomes possible to send and receive messages.

• ws_receiveframe: Receives a single frame (control frame or not) and saves it in a buffer provided by the user, does not perform dynamic memory allocations. CONT-type frames require multiple invocations to this routine. Return parameters and variables to inform frame content, type, error, and success conditions are important.

(I leave the parameters and return of the functions open, as this can change at any time).

It is also important to leave the management of client lists, pthreads, locks, etc, to the event-based implementation (or not, I'm still thinking about it). The idea is that this API becomes the foundation of the current API: which is higher-level and event-based.

PS: Any help on this issue is greatly appreciated as it requires a lot of rework of the source code =).

[domsson]

I'm not sure this will be applicable here, but when I worked on my Twitch IRC library, I introduced a tick() function which would take care of all the necessary work the library would do during one iteration of the main loop. The user could then write their own main loop (which could include other, arbitrary code) and simply call tick() within that loop. See the wiki on that project in case you want to see if you could potentially draw inspiration from it.

[Theldus]

Hello @domsson,
I don't know if an 'all-in-one' function is ideal for this case... I wanted to leave some things apart like: listening, accepting a connection, receiving frames, and leave the user to invoke them individually.

But you raised an interesting point: the approach I described in the issue was designed to use blocking routines: wait for a connection, wait for frames, and so on. In fact, the entire wsServer was designed this way.

Your approach on the other hand suggests non-blocking routines (and in fact for that you use epoll in your project). It would be interesting if these routines that I suggested could be non-blocking too so that the user could use them either with threads, select, poll, epoll, libevent, etc.

But maybe this requires even major changes in the source code since my routines couldn't block in the midst of a received frame for example, as they do at the moment.