Client Migration

Websocket.zig is being redesigned. Most of the changes are focused on the server implementation, but I've taken the opportunity to re-work the client code too.

Initialization

Instead of websocket.connect(allocator, host, port, opts), use websocket.Client.init(allocator, opts). The host and port are required fields of opts.

Explicit Read

While readLoop is still available (and the preferred approach), it is now possible to call client.read() !?websocket.Message to read an individual message. This will block until an error or message is received. Calling client.readTimeout(milliseconds) will cause read to return null on timeout.

Concurrent calls to read (or readLoop) are not allowed.

When read is used to read message, client.done(message) must be called on the returned message.

Handle Message

handleMessage has been renamed to serverMessage. This supports two overloads:

pub fn serverMessage(h: *Hander, data: []u8) !void

pub fn serverMessage(h: *Hander, data: []u8, tpe: websocket.MessageTextType) !void

Use the 2nd form if you care about the distinction between .text and .binary. (websocket.zig treats both the same)

Handler Capabilities

Instead of configuring the handle_pong, handle_ping and handle_close, the capabilities of your handler are automatically detected.

The following optional methods can be defined (and must be public):

pub fn serverPing(h: *Handler, data: []u8) !void
pub fn serverPong(h: *Handler, data: []u8) !void
pub fn serverClose(h: *Handler, data: []u8) !void
pub fn close(h: *Handler) void

Close

close now takes an option:

client.close(.{.code = 4000, .reason = "goodbye"});

Both the code and reason are optional.