XMPP Myths

http://wiki.xmpp.org/web/index.php?title=Myths

by AndrewDucker • 11 years ago

136 138 11 years ago

wiki.xmpp.org

SFjulie1• 11 years ago

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.

ADDENDUM technical issues in jabber: http://webcache.googleusercontent.com/search?q=cache:yGdLTF4...

nextos• 11 years ago

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.

FreeFull• 11 years ago

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.

rprospero• 11 years ago

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.

anon4• 11 years ago

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.

colechristensen• 11 years ago

So here's a question (and a personal manifesto)

Would things be better if they were worse?

That is, what if we gave a little bit less of a shit about optimizations and preferred simple over fast?

We live in a world of magical black boxes that even experts in the field have trouble manipulating. We need to protect and promote the Freedom to Tinker and that means carefully considering when optimizations are really critical hindrances.

joepie91_21• 11 years ago

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.

ape44• 11 years ago

absence of push

If you are connected and your buddy sends a message you get it right away.

niklasni1• 11 years ago

On mobile you want messages to come through without each app maintaining a connection.

sz4kerto3• 11 years ago

XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree)

What is 'difficult' in XML?

inversionOf4• 11 years ago

The notion that XML is difficult comes from the most profoundly lazy evaluations possible, where the most minimal of up front understanding are effort are eschewed if you can just launch mongodb and insert some giant mystery meat bags of json. We've seen this same mistake play out over, and over, and over again, and it is incredible that in a field where projects often end up taking thousands or more of man hours, people sweat and complain about 15 minutes up front gaining a basic understanding of a structure or API, and instead pursue solutions that, for instance, doesn't even have a date type or even consistent hack standard of how to handle it.

This is how we have the rapid trends in this field, where the new panacea is tomorrow's nightmare.

joepie91_21• 11 years ago

Dealing with it. Namespaces, attribute access, type-casting, the entire shebang.

JSON can be very easily natively represented in just about any language: you have objects/hashmaps/dicts, arrays, booleans, strings, numbers, and null. This means that accessing something in a JSON object is simple - you just use standard member access in your language of choice.

XML is considerably harder to use - you have children, and attributes. You have namespaces, and so on. These make it impossible to use a basic 'data model' like for JSON - instead you need interactive objects, that let you traverse the tree.

You can no longer simply map/filter/reduce over data. You can't easily access deeply nested structures without lots of syntax clutter. You can't easily serialize back and forth. Instead of using what your language already provides for data structures, you now need to learn an entirely new one, specifically for XML.

That is what is 'difficult' in XML - it considerably increases the cognitive load for working with it. You can't keep the structure in your head easily, but need to look at documentation instead, and need to learn a specific (often bulky!) API just to interact with the data.

Realistically, XML is useful for storage of complex data, but you really shouldn't be using it for wire serialization like XMPP does. XML is useful in a small subset of usecases, and trying to apply it to everything else is a mistake.

chrisseaton• 11 years ago

You can't quote a word and ask them to explain it if they didn't even use that word.

vog3• 11 years ago

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.

joepie91_21• 11 years ago

That is a browser issue, and does not exist in native clients. If we're talking about XML-stream-over-sockets, then comparing it to browsers makes no sense (because they can't do that!), and thus long-polling and JSON-over-HTTP become irrelevant.

EDIT: Hmm, did you edit your post? I don't recall the first part being there... anyhow:

XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol.

That is one factor, but the protocol complexities often seem to derive from the question 'how do we represent this in XML?', and that's an issue.

Another problem is the jargon - the MUC specification is utterly incomprehensible, because the terms it uses for things are so wildly different from how they are used everywhere else, that building a mental model is really hard. I've seen this issue in other XEPs as well.

Flowdalic9• 11 years ago

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.

That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.

Arathorn3• 11 years ago

+1 that JSON-over-WS is not a panacea. Long-polling is inelegant but is pretty efficient with HTTP/2.0, and trivially degrades on older HTTP stacks (e.g. in embedded devices) which don't know anything about WS.

Dave Cridland's wiki page makes some good points, but predictably it paints a very black and white view of the world. Some contentious points are:

1. Myth One: XMPP is XML, so it's too slow.

...there are obviously faster encodings than XML out there (e.g. CBOR), so this feels like a slightly specious point to argue. Sure the difference isn't that important on the clientside (perhaps more of an issue for squeezing every last drop out of a server), but why not acknowledge it?

2. Myth Two: The baseline is minimal, therefore XMPP is useless.

I'm not sure anyone claims XMPP is useless just because its baseline is minimal. The issue is instead the fragmentation caused by lack of interoperability profiles for all the different extensions. Statistically, if I pick an arbitrary XMPP client and an arbitrary XMPP server, the overlap of supported XEPs is unlikely to provide a good modern comms experience. If it was a "bug" for your client or server not to implement a given critical XEP, then fragmentation would be less of an issue.

3. Myth Three: It's too bandwidth-inefficient for mobile.

Just because you can successfully talk XMPP over a 9600bps link with 30s of latency doesn't mean that the default transport is bandwidth efficient(!) That said, the XEPs for constrained networks are a better justification.

4. Myth Four: XMPP is unreliable without a bunch of extensions.

As Dave repeatedly says, XMPP is a NAK protocol - by default messages are not acknowledged, so whenever a TCP stream drops you have no way of knowing whether the last messages in the stream got through or not. This is to me the definition of an unreliable delivery mechanism, and you have to mitigate it with extensions (XEP-198). I'm still not sure how this one's a myth...

5. Myth Five : XMPP is unsuited to the web.

The hypothesis of "XMPP is unsuited to the web because angle brackets and stuff" isn't exactly well articulated here. I think the actual complaint here is "why bother putting an XMPP stack in your browser when you already have an HTTP stack there"? What value do the remnants of XMPP's transport semantics have when you already have HTTP as a transport? I agree that Stanza.io & XMPP-FTW make this less clear cut, however.

For what it's worth, the FAQ entry that triggered this wiki page can be found at http://matrix.org/blog/faq/ (What’s the difference between Matrix and XMPP?).

rakoo4• 11 years ago

I also don't really understand the comparison with "JSON over HTTP"

One of the complainers is matrix (https://matrix.org/), which does JSON over HTTP.

treffer2• 11 years ago

Which has it's own set of problems, btw. Try to find an API for "delete".

Oh, and I'm eager to see how their API survives mutual parties extending it. (There is a reason why namespaces exists)

tbrownaw• 11 years ago

The correct technology is JSON-over-WebSockets,

No, it's ASN.1 DER over TCP. :)

wtbob3• 11 years ago

Or canonical S-expressions over TCP…

leni5362• 11 years ago

Or protobuf over TCP.

davecridland10• 11 years ago

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.

Hope that helps.

infie• 11 years ago

Mind sharing which desktop client you use (and on which OS)?

joepie91_21• 11 years ago

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.

I don't know how accurate Android's power estimates are, but I consistently have people telling me that they are switching back to proprietary messengers because every XMPP client they've tried drained their battery. Whatever causes it, there's a real problem here.

(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.

The problem is that theoretical future benefits are worthless if you never get a base implementation going. XMPP is just too hard for many developers - it's not a thing that you're going to understand well unless you work on it full-time, and that's not acceptable for a protocol.

Hitting XML directly is almost always a requirement. Libraries are woefully incomplete due to the large number of XEPs, and to implement anything yourself, you must understand the XML structure.

If the intention of XMPP or XMPP frameworks was to abstract away the XML, then they have failed.

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.

I experience constant issues with OTR, most servers don't seem to even support message carbons (nor do major clients like Pidgin have any useful indications of it), and frankly, I have never seen a single 'regular' user get synchronization set up correctly.

This is really a pervasive problem in the XMPP ecosystem: everything is too hard. Little to no thought seems to have gone into the UX, and unless you are an 'experienced XMPP user', you really have no clue what is going on. The experienced users say "meh, works for me" and don't set out to fix it.

This is true for the frameworks, the clients, and most of the servers. It's just all-around user-hostile, and that needs to change.

Flowdalic9• 11 years ago

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.

1: https://xmpp.org/extensions/xep-0352.html

joepie91_21• 11 years ago

What are your thoughts on http://op-co.de/blog/posts/mobile_xmpp_in_2014/ ?

zamalek2• 11 years ago

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] http://xmpp.org/extensions/xep-0286.html

joepie91_21• 11 years ago

JSON name conflicts are easily resolved by giving every extension its own key in the object. That's the equivalent of namespaces.

userbinator• 11 years ago

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.)

joepie91_21• 11 years ago

IRC has major issues, actually - notably, it's very tricky to parse correctly (and very easy to think you're parsing it correctly when you aren't), and doesn't support more than one space-containing value per 'line'. It's also implemented differently by every single server.

You will need some kind of serialization format for a reliable message protocol. JSON is just the simplest possible format that can reasonably represent common data, and works in 95% of the usecases.

haddr• 11 years ago

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.

hobarrera2• 11 years ago

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?

joepie91_21• 11 years ago

The idea is that push notifications are handled by a single platform vendor, and you thus only have one TCP connection to maintain for all applications together, instead of a separate connection for each application.

It's a form of batching.

ape44• 11 years ago

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.

insertnickname• 11 years ago

They did: "XEP-0295: JSON Encodings for XMPP" https://xmpp.org/extensions/xep-0295.html

:-)

ape44• 11 years ago

How about that! Then they need to publicize it. Make a website, say, jmpp.org (pronounced "jump") and a reference implementation.

hackerboos• 11 years ago

Serialization and de-serialisation should be abstracted. I should be able to use JSON, XML, TOML, YAML or MessagePack and just write a plugin.

jacobolus• 11 years ago

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.

slasaus2• 11 years ago

Don't forget Whisper Systems protocol used by TextSecure[1] which is based on Google's protobuf[2] and JSON in a REST api.

[1] https://github.com/WhisperSystems/TextSecure-Server/wiki/API...

[2] https://developers.google.com/protocol-buffers/

nickpsecurity9• 11 years ago

One could get started with PSYC. It's open.

http://about.psyc.eu/Introduction

Arathorn3• 11 years ago

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.

legulere• 11 years ago

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.

davecridland10• 11 years ago

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 standards@xmpp.org 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.

dhaneshnm• 11 years ago

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 ?

detaro• 11 years ago

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.

fbellag• 11 years ago

I'm always playing around with messaging for pet projects, and tried xmpp a couple of times.

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?

nickpsecurity9• 11 years ago

Here's an old critique of XMPP by author of PSYC protocol: http://about.psyc.eu/XMPP

I think it showed how its complexity vs value delivered tradeoff isnt so good. Decided against trying to implement the protocol.

Zash4• 11 years ago

So did you implement PSYC instead?

nickpsecurity9• 11 years ago

No. I already had a reliable communication system over UDP. I tweaked it with some stuff from PSYC and elsewhere. Let me achieve needed goals without doing a whole PSYC system. Had I needed full XMPP alternative I might have built PSYC just to see what would happen.

davecridland10• 11 years ago

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).

nickpsecurity9• 11 years ago

That is interesting. My initial guess would be one of the two:

(a) it's improved remarkably and such short comings don't exist

(b) it won in adoption, it's getting all the labor, and you two are simply trying to improve it on the technical council.

I'm going with (b) for now. Was I right? Or is XMPP now efficient, easy to understand, and easy to implement?

lep• 11 years ago

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.

[1] https://github.com/louiz/biboumi [2]: https://github.com/siacs/HttpUploadComponent

jessaustin3• 11 years ago

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.

davecridland10• 11 years ago

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.

XMPP Myths

Related Stories