What does write return? Does write block? Partial writes or something else?
This seams a little inconsistent in other systems as well:
There appear to be two different ways it's handled api wise.
Partially writing if you can't write everything at once and returning
either the length you've read or what data is remaining.
or
Blocking until all data can be written or returning and passing that
task off to a underlying layer.
NSPR seams to handle this the first way returning the length that wasn't
written.
Java uses the later and simply takes the data.
Ruby seams to have a write and write_nonblock which handle the later and
former behaviors.
Python's .write seams to take the latter behavior.
Api side the only thing we really care about is:
Do we do partial writes and return the remaining data or length of read.
Or do we just take the data and guarantee in some way the system will
attempt to write all of that data rather than only writing part of it.
Either way would probably work in a technical sense:
In C/C++ layers that do partials:
If we do partials, they are simple wrappers.
If we do full write, writing will either have to block or use some other
layer to do writing in the background.
In Java and layers that just write:
If we do partials, we'll just full write and return no data or 0 length
to imitate a partial write that really writes everything.
If we do full write, they are simple wrappers.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
I expect blocked writing by default. We do need an async version though.
This is probably a good time to mention that we've been playing with
the idea of having functions like "write" and "flush" that do not
generally return anything meaningful, return the context object, the
stream itself in this case. This lets us do chaining.
I also generally prefer to functions to consistently return the same
type of thing regardless of their arguments and options. Even open,
although it does not always return the same type necessarily, always
returns an object with a common API. For that reason, I would prefer
"write" and "async write" to have different names.
My present notion is to have write(content) -> this and
writeFrom(buffer, begin, end) -> actual:Number, analogous to read() ->
content, read(max:Number) -> content, and readInto(buffer, begin, end)
-> actual:Number, like the new Python IO API.
Kris Kowal
All of my experience with POSIX and Windows APIs tells me that whether
a read or write operation happens "asynchronously" (returns before
having read or written the fully requested amount) is a property of
the descriptor, and not of the operation.
> I prefer options over multiple methods like .write() and .write_nonblock()
I think both are bad ideas.
Here's some background:
http://www.ia.pw.edu.pl/~wujek/dokumentacja/gnu/libc/libc_8.html
I started a show of hands on the topic:
https://wiki.mozilla.org/ServerJS/Filesystem_API/Show_of_hands
Marked Wes as A.2 (partial writes, return length) and me and Kris as B
(blocking).
I'm unsure what Donny thinks.