I would assume the write-method in SSL.File should work with Stdio.Buffer.output_to(), but since it isn't implemented, I got worried I'm missing something in the big picture here...

Thats a great addition. Shouldn't SSL.File.write() be good enough to work with output_to() ?

I had some more changes in mind when it comes to how the buffer is used. In particular, I wanted to allow writing binary frames directly into the internal buffer to avoid one copy. The reason I did not do it was that the frame masking needs to do one copy anyway. For client mode that is not the case, so I might have a look at that now.

Arne

On 05/18/16 09:10, Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) @ Pike (-) developers forum wrote:

...

I've been spending some time in the realm of Protocols.WebSocket lately. I've been working on a client mode for it as it only contains the server side parts at the moment.

I now have a working version for Pike 8.0 (which is the version that I want it for) but when I tried to port it to 8.1 I ran into a bit of a problem.

It seems that the 8.1 branch has been rewritten to work with Stdio.Buffer, which is good. But from what I can tell, SSL.File does not support that API. Is there a reason for this?

Also, any objections to extending the WebSocket module in 8.0 to also provide a client mode?

Well, the problem is really that there is no set_buffer_mode() method in SSL.File.

Unless it is easy to fix that part (i.e. implement a buffered mode in SSL.File), I think the easiest thing to do is simply to rewrite the WebSockets module to not use buffered mode. We can still use Buffer objects instead of strings, we just have to output to the stream "manually"...

No, I think its my mistake. The Connection class should really work with anything Stdio.File-like, both in server and client mode (without masking).

arne

On 05/18/16 10:20, Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) @ Pike (-) developers forum wrote:

...

I would assume the write-method in SSL.File should work with Stdio.Buffer.output_to(), but since it isn't implemented, I got worried I'm missing something in the big picture here...

...

Thats a great addition. Shouldn't SSL.File.write() be good enough to work with output_to() ?

I had some more changes in mind when it comes to how the buffer is used. In particular, I wanted to allow writing binary frames directly into the internal buffer to avoid one copy. The reason I did not do it was that the frame masking needs to do one copy anyway. For client mode that is not the case, so I might have a look at that now.

Arne

On 05/18/16 09:10, Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) @ Pike (-) developers forum wrote:

...

I've been spending some time in the realm of Protocols.WebSocket lately. I've been working on a client mode for it as it only contains the server side parts at the moment.

I now have a working version for Pike 8.0 (which is the version that I want it for) but when I tried to port it to 8.1 I ran into a bit of a problem.

It seems that the 8.1 branch has been rewritten to work with Stdio.Buffer, which is good. But from what I can tell, SSL.File does not support that API. Is there a reason for this?

Also, any objections to extending the WebSocket module in 8.0 to also provide a client mode?

Ah, good. Then I might just ignore 8.1 for now and implement the client in 8.0.

Since it is an extension to the current module and doesn't really change any APIs (it just adds new ones) I'm guessing that isn't a problem.

Whats the general feeling about adding features to pike 8 at this point. I would personally like to backport the Stdio.Buffer C-API, which allows using Stdio.Buffer objects from other c modules. This specifically refers to 307d11f8635294f4250e01c3f5c6164272d4fee5.

arne

On 05/18/16 18:20, Peter Bortas @ Pike developers forum wrote:

As long as Grubba and Nilsson agrees with the result it's OK.