jdev - 2020-07-13

moparisthebest: I asked there about xmpp over websockets yesterday and got no response, do you have more info on that?

doesn't support that right now, I suspect you'll be hard pressed to find a non-web client that does, may I ask why you want that?

Gajim does though.

> doesn't support that right now, I suspect you'll be hard pressed to find a non-web client that does, may I ask why you want that? I am confused, what do you exactly refer to with "why you want that?"?

User1773717: well, if the client can already easily establish a standard TLS connection above a TCP socket, there's no intetest to use websockets for me. Indeed with websockets, you can't manage stream data, you can only work by full message chunk.

adrien, how is it an issue for XMPP?

There's no big problem I think, but it means you can't take advantage of buffering XMPP stream to an SAX xml parser directly. So, if you are able to manage the DNS, TLS and TCP stuff, I see no interest to propose to use WebSocket too.

adrien, fwiw, you can also use SAX with WebSocket framing; just means you need to reset the parser state for each message to some extent.

Indeed, but if the message data is heavy, you can't buffer it to the parser, you have to store it entierly in some place.

I suppose that depends on the websocket implementation

Nope, the XEP is clear about that: only full XMPP message must be sent

soo?

whether a websocket implementation allows you to stream the data into a streaming SAX parser is a websocket implementaiton detail, isn’t it?

Mmhh, I thought the Websocket `on_message` interface wasn't made to do streaming due to it's name.

possibly

also note that XMPP only guarantees stanza sizes up to 10 kB anyways; anything beyond that is implementation defined.

Nice, I didn't know about that limit. Now, I'm wondering how pubsub manage bigger data ☺

I have a lot to learn about xmpp :-)

XMPP says that a server's maximum stanza size must not be less than 10K.

You can phrase that as 'only guarantees stanza sizes up to 10K', but I think the give subtly different impressions.

true

adrien, I am not sure if xmpp impls ever should directly feed their network input to the parser

flow, what’s the alternative?

at least not without having some kind of stanza size enforcement in between

I tend to disagree

jonas’, maybe I did not a good job explaining what I mean. but if you just wrap the parser around the byte source, then you have no control over the stanza size and it often makes it harder to recover from an error

here: byte source == the tcp socket

with a SAX parser limits are pretty irrelevant, unless you store things somewhere. so you can simply "count" the size as you go while parsing, and when the data exceeds, you either kill the stream or forward (discarding data) until the end of the stanza

(though the latter is very interesting with stream management)

Well, that's the SAX parser which should leverage error if it has consumed too many bytes.

jonas’: exactly :-)

however, if you try to guess the stanza size before parsing with a proper XML parser, you end up re-doing much of the XML parsing.

which sounds painful

jonas’, I do mostly stax (pull) parsing, not sax (push) parsing, and there, counting the offset in the currently parsed stanza is some effort. is it easier with a typical sax API?

Even with pull it's relatively straightforward to say "There's been too much data read since the last stanza event" isn't it?

I don’t care about bytes in the end

Which isn't the same as a cut-off at a precise point, but does the job.

yeah, nodes is more interesting, though counting character data is also relevant

but both is not much of a big deal

Kev, sure you can always manually "count" the input. But I think ideally you want to able to tell the parser to set a mark and then be able to query the current offset from that mark ✏

adrien, re how pubsub manages bigger data: pick at least one of: (1) not (2) don't care or (3) split into smaller (4KiB) chunks

jonas’, sed to C translator written in sed : https://github.com/lhoursquentin/sed-bin