[ANN] tube 4.1 - Typesafe abstraction on top of Lwt_io channels

Community
#1

I’m happy to announce that tube is now available on OPAM.
It’s not much, but it’s a thing I was looking for a while when I was working with Lwt_io channels.

A typesafe abstraction on top of Lwt_io channels in order to avoid things like unsafe operations like Lwt_io.write_value / Lwt_io.read_value when running locally (i.e. as opposed to disk io, network io, etc, where marshalling of the messages is needed)

Haven’t thought very long on what will be the goal of this tiny library, but if someone finds it useful, and there’s really interest into it, I’m pretty sure we could find other features that could go into this.

Any feedback would be appreciated, thanks.

1 Like
#2

This seems like a useful library. Part of the functionality could be directly included in Lwt (I remember discussing some variant of this, but using non-generalizable type variables instead of functors).

I’m not sure what the pushback is for, since you don’t check that the returned value is the same than the original one.
One problem with your approach is that the marshall call itself is blocking and returns a string instead of sending on the channel directly. To remove this issue, you could provide an alternative functor that also takes the serialization/deserialization functions. See faraday and angstrom for Lwt-compatible APIs (@dinosaure also did experiments with this).

Also, please always add a .mli with some documentation in it. Even if the library is simple.

1 Like
#3

Thanks a lot for your feedback.
Regarding the pushback, basically, all it does is to “block” (put it on sleep, I guess would be the right lingo for this, meaning that the thread is not failed, nor returned) the Lwt thread until the value is being read from the other side; and in order to get that “effect”, I’ve used another Lwt_io pipe, and sending the output_channel of the intermediate pipe to the reader, and waiting for the confirmation on the intermediate input_channel; not entirely sure if this is the right approach, but so far worked pretty decent for me;
"One problem with your approach is that the marshall call itself is blocking and returns a string instead of sending on the channel directly. " - sorry, but really don’t know what the problem is here, as I know way too little about Marshal - honestly I’ve been using it only in order to be able to send over the channel things like another channel (i.e. I’m sending that t * Lwt_io.output_channel, thing that wasn’t possible if I wouldn’t specify that marshal instead).
And yes, I’ll try to add some .mli, although initially when I did that, something seemed very off, so I decided to keep it “simple” - but I’ll try to do it.
Again, thanks for taking your time to give some input on this.

Alin