Dino – Modern XMPP Chat Client using GTK+/Vala(github.com)
github.com
Dino – Modern XMPP Chat Client using GTK+/Vala
https://github.com/dino/dino
24 comments
How does Dino compare to Conversations when it comes to XEP support? There used to be a website that gave a quick overview of XMPP servers and clients but I can't find it for the life of me and I don't feel like doing a side by side comparison of two giant tables of XEP codenames...
https://xmpp.org/software/software-comparison/
>How does Dino compare to Conversations when it comes to XEP support?
It may not be on par, but it's more than "good enough" and nice to use imho with working (video) calls and encrypted group chats etc.
>How does Dino compare to Conversations when it comes to XEP support?
It may not be on par, but it's more than "good enough" and nice to use imho with working (video) calls and encrypted group chats etc.
> https://xmpp.org/software/software-comparison/
This tool is only useful if you know what XEPs actually matter, which is not most people (nor expected to be!).
https://xmpp.org/software/ is a better resource for most people, as it provides the compliance filters (each software entry being either "core" or "advanced" in different categories, depending on e.g. whether you want a web/mobile client, etc.).
As you can see, Dino is pretty up to date: https://xmpp.org/software/dino/
Conversations, for comparison: https://xmpp.org/software/conversations/
This tool is only useful if you know what XEPs actually matter, which is not most people (nor expected to be!).
https://xmpp.org/software/ is a better resource for most people, as it provides the compliance filters (each software entry being either "core" or "advanced" in different categories, depending on e.g. whether you want a web/mobile client, etc.).
As you can see, Dino is pretty up to date: https://xmpp.org/software/dino/
Conversations, for comparison: https://xmpp.org/software/conversations/
My wife, a few friends, and I use both Dino and Conversations to message each other and never ran into any feature missing between both of them. I'm sure there must be a few, as mentioned by others, but for day to day usage, they seem to be on par with each other.
I hear all the time how rubbish XML is to work with but there's loads of decent standards based on it. RSS, this, etc. HTML could be considered XML. Why's it considered so bad?
During the days of XML being the first JSON, the libraries available for handling XML documents were rather obtuse and pedantic. The view was that two XML entities that just had all the same names and values, but we're defined in different namespaces, were not the same entity. Everyone was pushing for the nost strict interpretation of things, under the idea that "stricter is safer".
So you couldn't just read and write a smattering of tags and attributes and expect anything to work. You needed to know what namespace each went in. There were rules about which ones required prefixes and which didn't. You needed very intimate knowledge of the data before you could ever read it, knowledge that may not have been easy to come by, given the documentation efforts were even worse back then than they are now.
And then JSON came around and said "screw all that, just overload the scripting engine itself to do parsing directly". Early JSON wasn't a standard, it was just a technique of taking a response body and calling `eval()` on it. It was wildly dangerous and--as most wildly dangerous things--incredibly freeing and intoxicating.
These days, the XML story has gotten better. Some newer versions of processing libraries are not as strict about namespacing--they will let you spit out whatever tag soup you want without being so officious. But the damage was done and now XML has a reputation.
So you couldn't just read and write a smattering of tags and attributes and expect anything to work. You needed to know what namespace each went in. There were rules about which ones required prefixes and which didn't. You needed very intimate knowledge of the data before you could ever read it, knowledge that may not have been easy to come by, given the documentation efforts were even worse back then than they are now.
And then JSON came around and said "screw all that, just overload the scripting engine itself to do parsing directly". Early JSON wasn't a standard, it was just a technique of taking a response body and calling `eval()` on it. It was wildly dangerous and--as most wildly dangerous things--incredibly freeing and intoxicating.
These days, the XML story has gotten better. Some newer versions of processing libraries are not as strict about namespacing--they will let you spit out whatever tag soup you want without being so officious. But the damage was done and now XML has a reputation.
I don't mind XML personally, but I understand why people dislike it. For XMPP specifically you have to use a streaming XML parser, which is quite a bit more complicated than the more common case of parsing XML into a tree and then traversing that tree. Not all XML libraries even have support for streaming parsers and if you start implementing XMPP with a non-streaming parser you'll end up with something really messy.
Streaming parsers give you a stream of events like "open tag 'message'", "attribute 'from'", "open tag 'body'", "close tag 'body'" and you need to gather those and translate them back into the top-level elements of the stream. This is pretty tedious, and if you do it wrong you may end up leaking memory (if you keep the entire tree around in memory) or even introduce vulnerabilities (similar to https://bugs.chromium.org/p/project-zero/issues/detail?id=22... ).
Streaming parsers give you a stream of events like "open tag 'message'", "attribute 'from'", "open tag 'body'", "close tag 'body'" and you need to gather those and translate them back into the top-level elements of the stream. This is pretty tedious, and if you do it wrong you may end up leaking memory (if you keep the entire tree around in memory) or even introduce vulnerabilities (similar to https://bugs.chromium.org/p/project-zero/issues/detail?id=22... ).
Sounds like one would just need to build some kind of observables/xpath mishmash for XML streaming, and that would mostly eliminate the problem.
> one would‡ <<just>>‡ need to build
Let's see what...
> some‡ kind‡ of observables/xpath mishmash‡ for XML streaming
which in the end still leads to:
> would‡ mostly‡ eliminate the problem
Solid programmer-think, right there!
You "just" need to magic up some stuff that in the end <<might>> solve the problem.
E A S Y - PEASY!
‡ LOL at the weasel word count.
Let's see what...
> some‡ kind‡ of observables/xpath mishmash‡ for XML streaming
which in the end still leads to:
> would‡ mostly‡ eliminate the problem
Solid programmer-think, right there!
You "just" need to magic up some stuff that in the end <<might>> solve the problem.
E A S Y - PEASY!
‡ LOL at the weasel word count.
At some point XML was everywhere: Deployment descriptors (j2ee), build files (ant), xHTML, debug log files (log4j), word documents, RPCs (xmlrpc up to the soap monster) etc ... One of the key point of having a textual format was its human readability but a lot of those forced use cases were not good for XML (like RPCs!) where it became as readable as binary. This what gave it its bad reputation. There are some niches where it survived when it was done well as a structured description language (SVG is excellent for example) but all the "schema less" craze right after the XML craze kind of killed it for its original purpose structured documents.
SVG is a quite terrible format which uses its own miniformats to express things, e.g. paths, instead if using XML.
If you apply validation, testing, document the protocol and use decent serialisation rather than string combinations, it's really not that bad. I'd even argue that it's better than JSON.
However, it was popular during a time when C++ (not C++11) was the language to go to, CI was a very manual process for most companies, CD was something only very small companies could do, and protocols were vague. Had we had JSON during the same time period, JSON would now be considered a terrible standard we should just abandon.
However, it was popular during a time when C++ (not C++11) was the language to go to, CI was a very manual process for most companies, CD was something only very small companies could do, and protocols were vague. Had we had JSON during the same time period, JSON would now be considered a terrible standard we should just abandon.
Well, JSON would have never been created in C++. The moral equivalent in statically compiled language was dumping struct memory raw out to files. And many programs did that, it just wasn't platform independent. JSON happened because more software was being written in JavaScript and, like most interpreted scripting language, doesn't care what you do, so long as what you do succeeds.
> Well, JSON would have never been created in C++.
Why? Marshalling is a common requirement that's not a monopoly of a single language, and there is no technical limitation on C++ that stops it from parsing any particular data interchange language.
> The moral equivalent in statically compiled language was dumping struct memory raw out to files.
If you've chosen to go the miopic path and focus on JSON's eval trick, you'd be missing the whole point of JSON.
If you're focusing on marshalling languages, you're somehow pretending that things like Apache Avro, Protocol Buffers, Apache Thrift, etc don't exist.
> And many programs did that, it just wasn't platform independent.
I don't think this is true at all. See examples above.
Why? Marshalling is a common requirement that's not a monopoly of a single language, and there is no technical limitation on C++ that stops it from parsing any particular data interchange language.
> The moral equivalent in statically compiled language was dumping struct memory raw out to files.
If you've chosen to go the miopic path and focus on JSON's eval trick, you'd be missing the whole point of JSON.
If you're focusing on marshalling languages, you're somehow pretending that things like Apache Avro, Protocol Buffers, Apache Thrift, etc don't exist.
> And many programs did that, it just wasn't platform independent.
I don't think this is true at all. See examples above.
> Why's it considered so bad?
The human margin of error is greater in XML implementations and usage compared to say, JSON. Here's a famous 0-day in Apple devices due to inconsistencies between XML parsers: https://blog.siguza.net/psychicpaper/
The human margin of error is greater in XML implementations and usage compared to say, JSON. Here's a famous 0-day in Apple devices due to inconsistencies between XML parsers: https://blog.siguza.net/psychicpaper/
I think it's primarily down to verbosity when working with it by hand and very heavy weight parsers being used for it frequently. There's just lighter weight, easier formats to work with and a lot of the standards that get piled on top of it lead to ever increasing complexity, xsd specifications, namespaces, etc.
Because the XML ecosystem is a mess. There have been many security issues caused by people using their XML parsers incorrectly (there are plenty of footguns) and no implementor ever seems to implement e.g. XSD, a standard for document schemas, completely or correctly. And don't get me started on SOAP.
I never understand these types of arguments as they always seem like different names for property lists. Some times a little more sometimes a little less but always plists.
The problem and advantage of XML is schema validation. If you don't validate you may not need XML.
[deleted]