Do we want buffering?

[jcrugzz]

Currently the setting is to drop any messages that are written to the client before it connects. This currently works for my use cases but it could be advantageous to buffer these messages to be sent in batch once the client does connect.

Thoughts?

[edef1c]

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

[jcrugzz]

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

[indexzero]

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

[edef1c]

Why should those have radically different semantics, @indexzero?

[indexzero]

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.

[indexzero]

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

[jcrugzz]

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

[indexzero]

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);

[jcrugzz]

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

[jcrugzz]

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

[indexzero]

Oh yeah? Well that's definitely worth changing.

[indexzero]

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.