Just reading through the #xmpp / #jabber core specification [www.rfc-editor.org] bc I initially wanted to write an own jabber <-> matrix bridge (the ones that exist either dont work anymore, aren't maintained or didn't work with my usecase), and I seriously consider just scraping that idea.
It's even more awefull of an protocol than HTTP; no length-prefix of messages, malformed xml, and genneraly try-and-error mentality for most of the protocol.
Gosh it gets worse; Not only do we use fucking SASL for the authentication layer, the protocoll also defines the ability to use two streams over two TCP connections or multiple streams over multiple TCP connections! Or in other words: a ducking logictical nightmare!!!
@mai_lapyst why would you need length prefixes for XML if you have closing tags? And where is the XML malformed?
@j_r Mainly malformed XML. The entire stream header is an open-ended xml blob, meaning all parsers that expect well-formed XML will cry out effectivly every time.
Also in an inheriently stream-based environment (TCP), you never know if the other side is done with sending you a portion of data or if it's just lag. Using a package-based communication with a length ensures that the data is correctly contained & seperated from other data that might be send over the same connection. And we've seen plenty of cases what happens when you dont have any length: take http smuggling for example. The cause why many modern websever just deny (nearly) any request without a Content-Length header and insta-close the connection.
@mai_lapyst @j_r it's not malformed it's just one continuous document (as you have correctly pointed out)
This means you start parsing once and don't stop parsing. (instead of for example trying to parse each stanza individually)
You need an XML stream parser that emits events for open and closed tags. This also means that you don't need length encoding. (which I guess you would need if you were trying to read the tcp packets as a string first and then stick each stanza into a new parser)
@mai_lapyst @j_r I can ensure you that most XMPP libraries use regular XML event parsers that aren't patched for any irregularities.
@rakoo Unless you write an own HTTP parser, HTTP server, own web framework or doing litterally anything on your own and not slapping everything to death with some overused & overrated libraries.
Sorry if i'm sounding mean; I'm just annoyed and mainly tired of the mentality of "just use a package brooooo" -.- I simply enjoy writing everything by myself :3 And I know that it will be hard, but I also dont need anyone talking to me like i'm 5 and that there are libraries for that stuff. Ik, but I choose to write it on my own. :3
@mai_lapyst XMPP works well
Of course, I don't know your use case, but I use #slidge matridge by @nicoco as #XMPP puppeteering gateway to Matrix. It works for me, but it has glitches. I.e. if you have time and (Python) skills at hand (and slidge matridge fits your use case), maybe you can help out?
@debacle My usecase is fairly simple: I do not want (or in this case can) just edit the xmpp server (it's a company-wide one). I just want to use my existing matrix client(s) as an client to this xmpp server; that means that ideally person X on that server would be X@company in my contact list, that itself is just an chat that incoming messages get dumped in and messages I dump into will get send off to the xmpp server.
So slidge (and a lot of others) are sadly not possible as it requires me to add a component to the xmpp server :/
Also I'm a python noob xD My skillset is more in native languages and ruby/js when it comes to scripting xDDDD
I see! It's more or less the opposite of slidge which you need. Sorry, no idea then
@debacle Yeah :/ Appritiate the input though! And yea, will post about it if I get something up and running :3