Hi, On Wed, May 18, 2016 at 5:28 PM, Mindy <[email protected]> wrote:
... > > I'm surely missing many things folks would want to incorporate in a big > API-breaking release -- please do let us know what they are. :) > I'd like to address some problems with `FLOW`, in particular: - the `read` function val read: flow -> [`Ok of buffer | `Eof | `Error of error ] io returns a fresh arbitrarily-sized buffer, which is inconvenient when unmarshalling data of known size. For example in ocaml-9p https://github.com/mirage/ocaml-9p/blob/cb9f5a6c83051ac5dfa7fc7a43ca6a2910a0a241/unix/flow_lwt_unix.ml#L50 we constantly allocate buffers of size 1k and read as many bytes as are available, even though at the higher-level the messages are preceded by fixed-size headers containing payload lengths. It would be better if the 9P client could have a single per-connection read and write buffer with length set to the dynamically-negotiated message size and then use a new function val read_info: flow -> buffer -> [ `Ok of unit | `Eof | `Error of error ] io This would make `FLOW` more similar to `BLOCK` -- Dave Scott
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
