Meh. None of these are claims I really see particularly often. The claims I do see are:
1. XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).
2. XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree). That is most likely what 'slow' refers to - not slow in parsing it, but in developing for it.
Neither of these are addressed.
I also don't really understand the comparison with "JSON over HTTP" - why would you ever use that for a realtime application?
The correct technology is JSON-over-WebSockets, and it doesn't really make sense to compare XMPP to a known-bad implementation and say "see? XMPP isn't that bad!"
Another issue with XMPP is the strange implementation of both resources and the existing options for sending to all resources (especially when taking into account tools like OTR). People want device synchronization, and it just isn't viable with XMPP right now.
While I agree that XMPP is not the future for app-to-app communication, I do so for a slightly different reasons.
> XML is unnecessarily complex for this kind of usecase
XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol. For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection. And there are more such surprises in XMPP. Good luck in understanding which "devices" (#xxxx) of the same Jabber ID will receive a message targeted at that ID.
It's really annoying and discouraging to debug that kind of issues - especially since these aren't bugs. These work as specified, but the specifications were obviously designed with direct human chatting or direct human collaboration in mind, programs being an afterthought.
> The correct technology is JSON-over-WebSockets
Not really. Whenever I saw someone trying this "in the wild", I see them quickly switching to HTTP long-polling. (Not to be confused with polling! We are still talking about instant push notifications with very low network overhead.)
For example, there are some libraries that used to provide wrappers around WebSockets, which switched to HTTP long-polling as fallback for old browsers. Nowadays, it seems they use long-polling by default, even though browser support becomes better and better.
Don't underestimate the role of firewalls and HTTP proxies! Many firewalls are aggressive configured, and many companies have forced HTTP proxies in place.
The specific claims I was responding to when writing this (and it's still a draft) were an HTTP-based JSON protocol whose FAQ makes all these claims and more. And yeah, I think it's dumb to do things that way (both JSON/HTTP and making ill-informed and misleading comments in your FAQ).
As to your comments:
(1) I'm just not seeing this. Even without mobile-style push, apps like Conversations appear way down the list in Android. Note that because XMPP maintains a continuous TCP session (or WebSocket, or whatever), then you get "push" in a general sense; that is, there is no polling.
Using an XMPP client on your mobile will, of course, have an impact on battery life, but I don't think a good client will drain your battery. For me, Conversations uses less power than Solitaire according to Android.
(2) I'll agree that XML does make the development of XMPP libraries more complex, but we gain because it grants very simple permissionless extension capability, and that's hugely valuable. If developers working with (rather than on) XMPP are having to hit XML directly, that is absolutely a problem.
Finally, resources are the way they are for all sorts of reasons, but Message Carbons really does work for having conversation sync across multiple devices. I often walk away from my desktop and continue conversations on my mobile and/or tablet, and wander back to the desktop when I feel the need to continue with a keyboard.
XML is unnecessarily complex but I think JSON also is.
IRC and MSNP (the early versions, before they started XML-ifying everything) are what I'd consider a good format protocol for the application - a mostly line-based, textual one you can use pretty easily without any client more complex than netcat. They are also extensible enough even without XML.
(Personally, I think it is absurd that a protocol needs to wrap a single text message, the most common form of message that would be encountered, in several times more bytes than the message itself.)
> XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).
There is actually an unbelievably good XEP (XMPP extension protocol) on mobile battery life.[1] I learned things from it: radio power states and so forth. It's incredibly detailed and educational and well worth the read even if you don't use XMPP. That being said, so far as actual implementations go, I have to agree with you.
> XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree). That is most likely what 'slow' refers to - not slow in parsing it, but in developing for it.
I have an ever-evolving conformant XMPP server pet project. What I found is that the framework takes bloody ages and I have to agree with you there. However, XMPP is a protocol that is ripe for elegant architecture and you can make a great framework. If you spend the time making a good framework the protocol is an absolute pleasure to develop against: but you have to make that initial time expenditure.
> The correct technology is JSON-over-WebSockets, and it doesn't really make sense to compare XMPP to a known-bad implementation and say "see? XMPP isn't that bad!"
Sort of. XMPP is one of the few applications that actually really makes use of the "eXtensible" bit in XML (where it's often misused as a dumb object graph). This means that you can do something as follows:
<message from='...' to='...'>
<body>You have work, go to http://... to action it.</body>
<form xmlns='urn:my-proprietary-stuff'>AF3BD2</form>
</message>
Any client that doesn't understand the <form> element would ignore it and present the message (allowing the user to click-through to the web UI). A client that does understand it would be able to do the special proprietary logic. Servers are also required (AFAIR) to pass on that unknown XML unaltered. You'd at least have a few problems in JSON due to name conflicts - which you could work around.
Either way, XMPP inherits a lot of traits from XML. You either need it or you don't and if you are using it there is a good chance that you are misusing it.
> 1. XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).
I never really understood this complaint. Why are the notifications sent via XMPP's TCP channel not considered "push"? How do you expect to get push notifications without an open TCP connection anyway?
> 1. XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).
I do use XMPP in a mobile environment without any noticeable impact on battery runtime. It's not the protocol which drains your battery, but how one uses it: If there is frequent activity in terms of XMPP stanzas being exchanged between your device and the device's XMPP server, then the device will be unable to e.g. put the radio to sleep. Which, in turn, is of course causing battery drain.
The golden rules to prevent that:
1. Only send XMPP stanzas when necessary
2. Bundle and defer outgoing stanzas if possible
3. Tell your XMPP service when the device is inactive, so that the service is able to optimize the traffic (XEP-352: Client State Indiation [1])
4. Consider service-side stanza blocking (e.g. XEP-16: Privacy Lists) for stanzas of "unknown" origin to prevent malicious users from draining your battery.
JSON over HTTP is not that bad concept. With the HTML5 server-sent events, this becomes a really cool stuff. And surprisingly it is working very well. For developers this is an order of magnitude easier and faster to develop rather than using low-level websockets which is reinventing the wheel.
FWIW, I added the following to the Wiki page when I saw it was on HN, which might help give some context to what you're reading:
Hi. I'm Dave Cridland. There's a note just up there which says "(Draft blog post)", and that's been there from the start - but when I asked for some feedback from the public [email protected] mailing list, people posted it on Twitter, and then it got onto Hacker News. Which is all cool, it's not secret, but...
This has not been properly reviewed yet (though the community is starting to), and so may contain inaccuracies, errors, or simply bad wording that's inadvertently as misleading as some of the comments I'm trying to rebut, and so feedback is genuinely welcomed.
Also equally welcome is feedback of the kind that says "Yeah, but I think that XMPP is entirely made by KILLING KITTENS", or whatever, so I can either write a rebuttal, or agree with you and try to get the community to fix it.
This is, currently, my personal opinion, and may not represent that of the XMPP community or the XMPP Standards Foundation.
Just for the record, I don't think we kill any kittens.
As always, when making these kind of statements, the question is: relative to what, and for what purpose? Without knowing that, it’s quite hard to know what the author of this page is getting at. Who is he arguing against, and what’s the context for these “myths”?
XMPP is sort of similar to all the browser technologies (HTML/DOM/CSS/etc.): it’s a large and complex spec which takes a large amount of work to implement even a basic version of, with lots of possible things to screw up.
It mixes various concerns together into a big jumble without the cleanest layering, which makes certain types of systems a pain to build on top of it. It’s based on a technology (XML) which is inherently heavyweight and not all that well suited to streaming applications. Tooling which exists around XML is mostly fairly irrelevant to an XMPP-like use case. If someone wanted to make an open IM protocol from scratch, they could make something much simpler, cleaner, and better organized.
On the other hand, all the other popular person-to-person IM protocols are proprietary, and XMPP is at least open, reasonably well documented, and with a relatively large community built up around it. Which counts for a lot.
If someone wants to build a new protocol, for example Google Wave, I would very strongly recommend against trying to shoehorn it into XMPP. On the other hand, if someone wants to make their chat client or server interoperate with existing chat networks, then XMPP is great.
The wiki page was in response to the XMPP bit of http://matrix.org/blog/faq. Coincidentally Matrix is a Wave-like protocol that hasn't been shoehorned into XMPP.
Apparently for me it is a myth that XMPP teams can make anything that works. And their site is logically down.
I am gonna make my grumpy old man. It still takes 1 day for an apprentice coder to :
- make an irc bot;
- program a rs232 port;
- to draw a pitcure accessing a framebuffer;
- to make hello world in Tcl/Tk that is centered horizontally and vertically in a bigger canvas.
But seasoned devs cannot easily do the same with:
- xmpp;
- usb;
- css/js...
Either the quality of the devs is going down, or some progresses are not.
While I'll join you in demanding the kids off our lawns, I'm looking forward to seeing 120V AC run through the very last serial port. There's nothing like sending a message down the serial power and seeing nothing come back. So many wonderful ways to fail.
Does this device require a null modem cable?
When the manual said that all commands needed to be terminated with a '\n', did they actually mean "\r\n" and not mention it?
Am I sending ASCII bytes to a piece of hardware that expects strings of UTF-16, without documenting it?
Did one of the students swap the cables and I'm just talking to a deactivated motor controller?
Has this particular serial cable finally bit the dust?
Is the hardware expecting me to transmit data on pin seven for some ungodly reason?
Did one of the students swap the the detector cable and the pre-amp high voltage line and fry the board I'm trying to talk to?
These are all issues that I've had to contend with on serial communications. The big catch is that it's usually not just one of these problems, so I wind up needing to check every possible combination. Having a device on USB saves me a boatload of trouble. The devices hooks up to the computer through a single, standard type of cable. If I can see the device after I plug it in, it's a software problem. If I don't see it, there's a hardware problem. Just from the above scenarios, seeing the equipment NOT connect eliminates 75% of the phase space for the problem. If I DO see the hardware, I've cut out 96%. So much easier to debug with USB.
This is so true. XMPP is quite complex. Complex to the point that bringing up a possible bug on either GTalk generating XML or Mcabber parsing it will leave some seasoned XMPP developers scratching their heads for a while, till they find the source of the problem.
It's sad, because we don't have that many decentralized multiplatform protocols. I had high hopes for Signal, but so far there is just one closed server.
Protocols are getting more complicated. Sometimes needlessly - XMPP; sometimes out of necessity - we can't let you poke bits in the framebuffer directly, because the graphics card is now this almost-blackbox superscalar coprocessor that only incidentally maybe has a display hooked to a tiny little region of memory that you could perhaps think of as a "framebuffer", but the framebuffer is actually not linear, but tiled in some weird way for performance.
Actually making the complex and simple stuff coexist on the same system is a very... complicated challenge.
I have a feeling that USB's complexity is there for good reasons. As far as xmpp and css/js go, there definitely is a lot of complexity that could have been avoided with a different initial design, although hindsight is 20/20.
The advantage of JSON is that it's way easier to handle because it maps directly to structures that are available in every common programming language.
I agree that XML is only slightly more verbose than JSON but they should still make a JSON version of the spec or it will die. It should be pretty straight forward to mechanically change the XML into JSON.
Worth noting that two of the people fairly heavily quoted on the shortcomings of XMPP both serve on the XMPP technical Council at the moment. (One of them is me, the other is Philipp Hancke).
Ofcourse if i (or anybody else) would write a chat protocol today i would make
changes. But i'm not even sure if i would abandon xml. I'm in the same boat as
you and think xml is too verbose and all that other stuff but i've recently
programmed some xmpp projects and i came to the conclusion that xml actually
realy does work well. And i didn't even use a library like sleekxmpp because
i wanted to know everything.
I'll just say: good luck designing something that'll be able to grow for 20 years
and still work today. You can realy feel where the X in XMPP comes from.
I have to mention the Conversations people. For me they are a big reason why i
use xmpp. It's not only the client which is very good, but the stuff like http-uploads
fix some very real problems in very little amount of code.
Also once axolotl-xmpp works and prosody 0.10 is released i see no reason not
to use xmpp honestly, which i will regardless, even if everybody uses something
else (like WhatsApp) i will simply write myself a transport server and continue
to use Conversations.
While i don't use it, projects like biboumi are realy cool. With a simple
combination of biboumi[1] and httpuploadcomponent[2] you now can share files
in irc-rooms.
I still have more to say. I hope that once i have my perfect chat-setup i will
write about it.
From where I sit typing this, I can look out of my window and see Bryn Myrddin - Merlin's Hill - underneath which, legend says, Merlin lies asleep, awaiting a time when England in is peril once more. This is a problematic myth, since Bryn Myrddin isn't in England...
"Merlin" might or might not be based on any historical figure, and such figure might or might not lie under that hill, and if so he probably knew a few Angles, but he never heard of "England", because it didn't exist for centuries after he might or might not have been active.
Thanks for picking up on the important content there. ;-)
If you want to be pedantic, Merlin - assuming he existed in the most likely timeframe - probably was aware of Angleland to his east, and would have been defending against its encroachment. (This based on the rise of Arthur as a popular name around 550AD as I recall, during the "Saxon" invasion largely carried out by Angles). The country he lived in was probably called something like Britain, though may have simply been closer to Cymru.
But I was largely paraphrasing T.H. White's Once And Future King, which in turn cribs the La Morte d'Arthur, which forms the basis for the "modern" Arthurian legend, and recasts it in an idealized England.
I find it strange that, nobody has mentioned MQTT so far in this discussion. Isn't MQTT also a 'competitor' for XMPP, besides JSON-over-Websockets? especially on mobile devices ?
It is not really a competitor for XMPP. It transports messages and you could build a chat service on top of it, so it is in a somewhat related space, but XMPP and MQTT aim at very different things.
[+] [-] joepie91_|10 years ago|reply
1. XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).
2. XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree). That is most likely what 'slow' refers to - not slow in parsing it, but in developing for it.
Neither of these are addressed.
I also don't really understand the comparison with "JSON over HTTP" - why would you ever use that for a realtime application?
The correct technology is JSON-over-WebSockets, and it doesn't really make sense to compare XMPP to a known-bad implementation and say "see? XMPP isn't that bad!"
Another issue with XMPP is the strange implementation of both resources and the existing options for sending to all resources (especially when taking into account tools like OTR). People want device synchronization, and it just isn't viable with XMPP right now.
[+] [-] vog|10 years ago|reply
> XML is unnecessarily complex for this kind of usecase
XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol. For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection. And there are more such surprises in XMPP. Good luck in understanding which "devices" (#xxxx) of the same Jabber ID will receive a message targeted at that ID.
It's really annoying and discouraging to debug that kind of issues - especially since these aren't bugs. These work as specified, but the specifications were obviously designed with direct human chatting or direct human collaboration in mind, programs being an afterthought.
> The correct technology is JSON-over-WebSockets
Not really. Whenever I saw someone trying this "in the wild", I see them quickly switching to HTTP long-polling. (Not to be confused with polling! We are still talking about instant push notifications with very low network overhead.)
For example, there are some libraries that used to provide wrappers around WebSockets, which switched to HTTP long-polling as fallback for old browsers. Nowadays, it seems they use long-polling by default, even though browser support becomes better and better.
Don't underestimate the role of firewalls and HTTP proxies! Many firewalls are aggressive configured, and many companies have forced HTTP proxies in place.
[+] [-] davecridland|10 years ago|reply
As to your comments:
(1) I'm just not seeing this. Even without mobile-style push, apps like Conversations appear way down the list in Android. Note that because XMPP maintains a continuous TCP session (or WebSocket, or whatever), then you get "push" in a general sense; that is, there is no polling.
Using an XMPP client on your mobile will, of course, have an impact on battery life, but I don't think a good client will drain your battery. For me, Conversations uses less power than Solitaire according to Android.
(2) I'll agree that XML does make the development of XMPP libraries more complex, but we gain because it grants very simple permissionless extension capability, and that's hugely valuable. If developers working with (rather than on) XMPP are having to hit XML directly, that is absolutely a problem.
Finally, resources are the way they are for all sorts of reasons, but Message Carbons really does work for having conversation sync across multiple devices. I often walk away from my desktop and continue conversations on my mobile and/or tablet, and wander back to the desktop when I feel the need to continue with a keyboard.
Hope that helps.
[+] [-] userbinator|10 years ago|reply
IRC and MSNP (the early versions, before they started XML-ifying everything) are what I'd consider a good format protocol for the application - a mostly line-based, textual one you can use pretty easily without any client more complex than netcat. They are also extensible enough even without XML.
(Personally, I think it is absurd that a protocol needs to wrap a single text message, the most common form of message that would be encountered, in several times more bytes than the message itself.)
[+] [-] zamalek|10 years ago|reply
There is actually an unbelievably good XEP (XMPP extension protocol) on mobile battery life.[1] I learned things from it: radio power states and so forth. It's incredibly detailed and educational and well worth the read even if you don't use XMPP. That being said, so far as actual implementations go, I have to agree with you.
> XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree). That is most likely what 'slow' refers to - not slow in parsing it, but in developing for it.
I have an ever-evolving conformant XMPP server pet project. What I found is that the framework takes bloody ages and I have to agree with you there. However, XMPP is a protocol that is ripe for elegant architecture and you can make a great framework. If you spend the time making a good framework the protocol is an absolute pleasure to develop against: but you have to make that initial time expenditure.
> The correct technology is JSON-over-WebSockets, and it doesn't really make sense to compare XMPP to a known-bad implementation and say "see? XMPP isn't that bad!"
Sort of. XMPP is one of the few applications that actually really makes use of the "eXtensible" bit in XML (where it's often misused as a dumb object graph). This means that you can do something as follows:
Any client that doesn't understand the <form> element would ignore it and present the message (allowing the user to click-through to the web UI). A client that does understand it would be able to do the special proprietary logic. Servers are also required (AFAIR) to pass on that unknown XML unaltered. You'd at least have a few problems in JSON due to name conflicts - which you could work around.Either way, XMPP inherits a lot of traits from XML. You either need it or you don't and if you are using it there is a good chance that you are misusing it.
[1]: http://xmpp.org/extensions/xep-0286.html
[+] [-] tbrownaw|10 years ago|reply
No, it's ASN.1 DER over TCP. :)
[+] [-] sz4kerto|10 years ago|reply
What is 'difficult' in XML?
[+] [-] hobarrera|10 years ago|reply
I never really understood this complaint. Why are the notifications sent via XMPP's TCP channel not considered "push"? How do you expect to get push notifications without an open TCP connection anyway?
[+] [-] Flowdalic|10 years ago|reply
I do use XMPP in a mobile environment without any noticeable impact on battery runtime. It's not the protocol which drains your battery, but how one uses it: If there is frequent activity in terms of XMPP stanzas being exchanged between your device and the device's XMPP server, then the device will be unable to e.g. put the radio to sleep. Which, in turn, is of course causing battery drain.
The golden rules to prevent that:
1. Only send XMPP stanzas when necessary
2. Bundle and defer outgoing stanzas if possible
3. Tell your XMPP service when the device is inactive, so that the service is able to optimize the traffic (XEP-352: Client State Indiation [1])
4. Consider service-side stanza blocking (e.g. XEP-16: Privacy Lists) for stanzas of "unknown" origin to prevent malicious users from draining your battery.
1: https://xmpp.org/extensions/xep-0352.html
[+] [-] rakoo|10 years ago|reply
One of the complainers is matrix (https://matrix.org/), which does JSON over HTTP.
[+] [-] haddr|10 years ago|reply
[+] [-] ape4|10 years ago|reply
If you are connected and your buddy sends a message you get it right away.
[+] [-] davecridland|10 years ago|reply
Hi. I'm Dave Cridland. There's a note just up there which says "(Draft blog post)", and that's been there from the start - but when I asked for some feedback from the public [email protected] mailing list, people posted it on Twitter, and then it got onto Hacker News. Which is all cool, it's not secret, but...
This has not been properly reviewed yet (though the community is starting to), and so may contain inaccuracies, errors, or simply bad wording that's inadvertently as misleading as some of the comments I'm trying to rebut, and so feedback is genuinely welcomed.
Also equally welcome is feedback of the kind that says "Yeah, but I think that XMPP is entirely made by KILLING KITTENS", or whatever, so I can either write a rebuttal, or agree with you and try to get the community to fix it.
This is, currently, my personal opinion, and may not represent that of the XMPP community or the XMPP Standards Foundation.
Just for the record, I don't think we kill any kittens.
[+] [-] jacobolus|10 years ago|reply
XMPP is sort of similar to all the browser technologies (HTML/DOM/CSS/etc.): it’s a large and complex spec which takes a large amount of work to implement even a basic version of, with lots of possible things to screw up.
It mixes various concerns together into a big jumble without the cleanest layering, which makes certain types of systems a pain to build on top of it. It’s based on a technology (XML) which is inherently heavyweight and not all that well suited to streaming applications. Tooling which exists around XML is mostly fairly irrelevant to an XMPP-like use case. If someone wanted to make an open IM protocol from scratch, they could make something much simpler, cleaner, and better organized.
On the other hand, all the other popular person-to-person IM protocols are proprietary, and XMPP is at least open, reasonably well documented, and with a relatively large community built up around it. Which counts for a lot.
If someone wants to build a new protocol, for example Google Wave, I would very strongly recommend against trying to shoehorn it into XMPP. On the other hand, if someone wants to make their chat client or server interoperate with existing chat networks, then XMPP is great.
[+] [-] slasaus|10 years ago|reply
[1] https://github.com/WhisperSystems/TextSecure-Server/wiki/API...
[2] https://developers.google.com/protocol-buffers/
[+] [-] Arathorn|10 years ago|reply
[+] [-] nickpsecurity|10 years ago|reply
http://about.psyc.eu/Introduction
[+] [-] SFjulie1|10 years ago|reply
I am gonna make my grumpy old man. It still takes 1 day for an apprentice coder to :
- make an irc bot; - program a rs232 port; - to draw a pitcure accessing a framebuffer; - to make hello world in Tcl/Tk that is centered horizontally and vertically in a bigger canvas.
But seasoned devs cannot easily do the same with:
- xmpp; - usb; - css/js...
Either the quality of the devs is going down, or some progresses are not.
ADDENDUM technical issues in jabber: http://webcache.googleusercontent.com/search?q=cache:yGdLTF4...
[+] [-] rprospero|10 years ago|reply
Does this device require a null modem cable?
When the manual said that all commands needed to be terminated with a '\n', did they actually mean "\r\n" and not mention it?
Am I sending ASCII bytes to a piece of hardware that expects strings of UTF-16, without documenting it?
Did one of the students swap the cables and I'm just talking to a deactivated motor controller?
Has this particular serial cable finally bit the dust?
Is the hardware expecting me to transmit data on pin seven for some ungodly reason?
Did one of the students swap the the detector cable and the pre-amp high voltage line and fry the board I'm trying to talk to?
These are all issues that I've had to contend with on serial communications. The big catch is that it's usually not just one of these problems, so I wind up needing to check every possible combination. Having a device on USB saves me a boatload of trouble. The devices hooks up to the computer through a single, standard type of cable. If I can see the device after I plug it in, it's a software problem. If I don't see it, there's a hardware problem. Just from the above scenarios, seeing the equipment NOT connect eliminates 75% of the phase space for the problem. If I DO see the hardware, I've cut out 96%. So much easier to debug with USB.
[+] [-] nextos|10 years ago|reply
It's sad, because we don't have that many decentralized multiplatform protocols. I had high hopes for Signal, but so far there is just one closed server.
[+] [-] anon4|10 years ago|reply
Actually making the complex and simple stuff coexist on the same system is a very... complicated challenge.
[+] [-] FreeFull|10 years ago|reply
[+] [-] legulere|10 years ago|reply
[+] [-] ape4|10 years ago|reply
[+] [-] insertnickname|10 years ago|reply
:-)
[+] [-] hackerboos|10 years ago|reply
[+] [-] nickpsecurity|10 years ago|reply
I think it showed how its complexity vs value delivered tradeoff isnt so good. Decided against trying to implement the protocol.
[+] [-] davecridland|10 years ago|reply
[+] [-] Zash|10 years ago|reply
[+] [-] lep|10 years ago|reply
I have to mention the Conversations people. For me they are a big reason why i use xmpp. It's not only the client which is very good, but the stuff like http-uploads fix some very real problems in very little amount of code.
Also once axolotl-xmpp works and prosody 0.10 is released i see no reason not to use xmpp honestly, which i will regardless, even if everybody uses something else (like WhatsApp) i will simply write myself a transport server and continue to use Conversations.
While i don't use it, projects like biboumi are realy cool. With a simple combination of biboumi[1] and httpuploadcomponent[2] you now can share files in irc-rooms.
I still have more to say. I hope that once i have my perfect chat-setup i will write about it.
[1]: https://github.com/louiz/biboumi [2]: https://github.com/siacs/HttpUploadComponent
[+] [-] jessaustin|10 years ago|reply
"Merlin" might or might not be based on any historical figure, and such figure might or might not lie under that hill, and if so he probably knew a few Angles, but he never heard of "England", because it didn't exist for centuries after he might or might not have been active.
[+] [-] davecridland|10 years ago|reply
If you want to be pedantic, Merlin - assuming he existed in the most likely timeframe - probably was aware of Angleland to his east, and would have been defending against its encroachment. (This based on the rise of Arthur as a popular name around 550AD as I recall, during the "Saxon" invasion largely carried out by Angles). The country he lived in was probably called something like Britain, though may have simply been closer to Cymru.
But I was largely paraphrasing T.H. White's Once And Future King, which in turn cribs the La Morte d'Arthur, which forms the basis for the "modern" Arthurian legend, and recasts it in an idealized England.
[+] [-] fbellag|10 years ago|reply
Honest question for edification and future play around projects: what alternatives do exist, fixing the issues presented here?
I'd love a lean, multiplatform api, with presence, multi-user chat, extensible for my use case, etc.
Recommendations?
[+] [-] dhaneshnm|10 years ago|reply
[+] [-] detaro|10 years ago|reply