Do we want buffering? about godot HOT 19 OPEN

imo this is a fairly obvious footgun — things like writing startup messages immediately and such should be simple.

from godot.

@nathan7 agreed, I will make it handle those cases.

from godot.

-1 to generic buffering, but +1 to pre-connect buffering.

from godot.

Why should those have radically different semantics, @indexzero?

from godot.

I don't think they do. Let me rephrase: godot should never do any buffering. The "pre-connect buffering" I was referring to would be the godot instance writing immediately to a net TCP or UDP stream which (thanks to streams2 and streams3) does the buffering for us if we haven't yet connected.

from godot.

Yes. Going to close this. We should always write immediately which will be easily buffered by Socket instances returned from net.connect

from godot.

@indexzero i brought this up for the case of before we have created a socket but we have a godot client instance.

from godot.

Sockets are instantly created by node. They may not immediately connect, but their internal buffering mechanism is available immediately:

var sock = net.connect('127.0.0.1', 7731);

from godot.

Hmm, I'm thinking the godot client itself should just be a simple stream itself and auto connect when initialized to prevent the need for this

from godot.

@indexzero yes but godot.createClient(options) does not create a socket. this is the behavior I want to change.

from godot.

Oh yeah? Well that's definitely worth changing.

from godot.

Mmmmmmm ... I see the problem here. Maybe we should change the syntax from

var client = godot.createClient(options);

to

var client = godot.connect(options);

The difference in semantics here is subtle but important. Overall my goal here is to push the buffering logic onto core as much as possible.

from godot.

@indexzero yea i like it. keeps us semantically the same as core and gives an easy way to remove the connect method from the internal client prototype since we would just be constructing a client instance.

from godot.

I would actually say keep the connect method on the client instance. The semantic in the docs would be:

How does Buffering work in godot?

Both the server and client instances of godot do no internal buffering themselves. For connected clients buffering is performed by Node.js core net and dgram modules. Connected clients are created by calling:

var client = godot.connect(options);

Or

var client = godot.createClient(options);

I'm not opposed to dropping createClient and the connect prototype method, but we should evaluate if we want to make that kind of breaking change first.

from godot.

Can't edit the comment from my phone but the second code sample above should be:

var client = godot.createClient(options);
clients.connect();

from godot.

@indexzero we could technically keep it but just have it called in the constructor if we truly want to have buffering handled by the tcp socket (udp won't buffer since its not a stream). I personally say its worth it for simplicity and add it as an extra addition to v1 as we are still in dev there.

The other piece I'm thinking about is having var client = godot.connect() return an actual stream we can pipe to. This would allow us to hook in buffering for udp if we wanted or we just make it a simple streams1 stream and just have the convenience of a simple pipe. This would just make everything semantically the same which I think would be quite nice.

from godot.

Do we want to go so far as to implement a fully buffered WritableStream instance in godot?

from godot.

@indexzero I'm thinking yes, but at the very least it should be a streams1 stream. From a method standpoint it already meets the requirement.

from godot.

the client is the only place i see it making sense.

from godot.