31–40 of 41 posts
Funny to me how asynchronous messaging seems to be more useful to people - would not have predicted that.
Earlier quoted context omitted.
Premature optimisation is the root of all evil. If you're deeply concerned with real-world operations, you should be painfully aware of this. XMPP is primarily an instant messaging protocol. An overhead of 50% is nothing if the payload itself is often just a few bytes, and a few kilobytes at most. Of course it makes XMPP unsuitable for a few scenarios, but in almost all cases, XMPP message traffic will be dwarfed by…
> Premature optimisation is the root of all evil. Argument by cliché, and a badly misunderstood one, at that. It's not a pass to engage in poor design practices. Would you deploy bubblesort on the grounds that quicksort is a premature optimization? > An overhead of 50% is nothing if the payload itself is often just a few bytes, and a few kilobytes at most You've just given me an estimated range of three orders of mag…
Unless it turns out the sorting routine has a significant impact on the overall performance, I wouldn't care a bit if it used Bubblesort, Quicksort or Bogosort.
> You've just given me an estimated range of three orders of magnitude. As it happens, that is also the range I commonly get from people who have just "designed" a protocol with zero thought.
Argument by snark. The assumption is that a chat protocol is developed for certain payload sizes because there is a trade-off involved: you'd do things differently if you had to create a protocol that works for 5 byte messages exactly as well as it does for 5 GB messages. Under that assumption, it's perfectly reasonable to give a range of expected message sizes. And since Jabber was developed in the first place as an IM protocol, 5 to 5000 bytes seems about right, with the distribution heavily skewed towards smaller messages.
> When I'm trying to process 10,000 messages per second on a CPU, and most of the overhead is already in ingesting, parsing, and routing each message, a 50% increase in message quantity means I need 50% more CPUs.
Yes. So? How many people are running large enough Jabber servers that this is a problem for them? And why can't they simply buy another CPU?
Earlier quoted context omitted.
> Premature optimisation is the root of all evil. Argument by cliché, and a badly misunderstood one, at that. It's not a pass to engage in poor design practices. Would you deploy bubblesort on the grounds that quicksort is a premature optimization? > An overhead of 50% is nothing if the payload itself is often just a few bytes, and a few kilobytes at most You've just given me an estimated range of three orders of mag…
> Would you deploy bubblesort on the grounds that quicksort is a premature optimization? Unless it turns out the sorting routine has a significant impact on the overall performance, I wouldn't care a bit if it used Bubblesort, Quicksort or Bogosort. > You've just given me an estimated range of three orders of magnitude. As it happens, that is also the range I commonly get from people who have just "designed" a protoc…
By your evident logic, then, Bogosort is the right default choice, because anything else is premature optimization.
> Yes. So? How many people are running large enough Jabber servers that this is a problem for them?
Well, the person I originally replied to appears to have been one of them. As are Google, Microsoft, AOL, Facebook, and Yahoo. I know one much smaller company I can't name who did field trials of XMPP on their embedded consumer device and promptly dropped the project.
Had I made the mistake of trying the same thing, I would now be in such a position.
> And why can't they simply buy another CPU?
And the server to put it in, and the space, and the power, and the cooling. I might be able to get a chip delivered for $200, but it's going to cost me another $400-800 plus people time to put it into service, and another $500+/year to run it.
Far cheaper to make the engineer spend a day or two to come up with something reasonable.
Earlier quoted context omitted.
> Would you deploy bubblesort on the grounds that quicksort is a premature optimization? Unless it turns out the sorting routine has a significant impact on the overall performance, I wouldn't care a bit if it used Bubblesort, Quicksort or Bogosort. > You've just given me an estimated range of three orders of magnitude. As it happens, that is also the range I commonly get from people who have just "designed" a protoc…
> Unless it turns out the sorting routine has a significant impact on the overall performance, I wouldn't care a bit if it used Bubblesort, Quicksort or Bogosort. By your evident logic, then, Bogosort is the right default choice, because anything else is premature optimization. > Yes. So? How many people are running large enough Jabber servers that this is a problem for them? Well, the person I originally replied to…
How does that follow from my logic? What I said was: I don't care about implementation details unless it turns out to be relevant. If I spent 99% of my time waiting for IO, and 1% on sorting, then yeah, the sort routine could be Bogosort for all I care, since the potential gains are tiny.
The right default choice for sorting is your standard library's sort routine. If you use that and sorting still takes a long time, then you can worry about what goes on in there and if it's worth replacing it.
> As are Google, Microsoft, AOL, Facebook, and Yahoo.
All of which now use XMPP despite the overhead.
Earlier quoted context omitted.
> Unless it turns out the sorting routine has a significant impact on the overall performance, I wouldn't care a bit if it used Bubblesort, Quicksort or Bogosort. By your evident logic, then, Bogosort is the right default choice, because anything else is premature optimization. > Yes. So? How many people are running large enough Jabber servers that this is a problem for them? Well, the person I originally replied to…
> By your evident logic, then, Bogosort is the right default choice, because anything else is premature optimization. How does that follow from my logic? What I said was: I don't care about implementation details unless it turns out to be relevant. If I spent 99% of my time waiting for IO, and 1% on sorting, then yeah, the sort routine could be Bogosort for all I care, since the potential gains are tiny. The right de…
Then you are reckless. It is both possible and desirable to anticipate obvious problems in a design and avoid them before they present themselves operationally.
> The right default choice for sorting is your standard library's sort routine.
Smarter people than you or I decided what the standard library's sort routine would be, and did so with careful consideration of the advantages and disadvantages of their choice.
Here we are speaking of the design of a protocol from scratch, and/or the explicit choice of a protocol for a given set of requirements. It is your duty to do as the standard library author did, and pay careful consideration to the implications of your design, as it will impact your business for years to come.
> All of which now use XMPP despite the overhead.
They have an interoperability requirement. Did you miss that detail of my earlier comment?
Is this live yet ? Just tried to add msn contacts to my jabber client and we couldn't make it work.
The client-to-server authentication used is SASL, with a specific and proprietary mechanism called X_MESSENGER_OAUTH2. ... Which means that all current XMPP clients are NOT able to connect to messenger.live.com.
http://www.process-one.net/en/blogs/article/details_on_msns_...
Earlier quoted context omitted.
> By your evident logic, then, Bogosort is the right default choice, because anything else is premature optimization. How does that follow from my logic? What I said was: I don't care about implementation details unless it turns out to be relevant. If I spent 99% of my time waiting for IO, and 1% on sorting, then yeah, the sort routine could be Bogosort for all I care, since the potential gains are tiny. The right de…
> I don't care about implementation details unless it turns out to be relevant. Then you are reckless. It is both possible and desirable to anticipate obvious problems in a design and avoid them before they present themselves operationally. > The right default choice for sorting is your standard library's sort routine. Smarter people than you or I decided what the standard library's sort routine would be, and did so…
> They have an interoperability requirement. Did you miss that detail of my earlier comment?
Some of them do. Some of them explicitly turn off interoperability and still go with XMPP; Whatsapp (no affil) is another one of those. This just stresses the fact that efficiency/overhead is not the only consideration when it comes to protocol choice, and pretty far down the line when it comes to IM protocols.
Is it on the roadmap for Pidgin (or libpidgin) or Adium?
I tried doing some quick Googling, but I couldn't find any answers...
It still looks a bit rough, e.g "Roster management is not supported" . I wish it would not end up being just a client concern but also impact server-side at some point thanks to XMPP federation. Google Talk does federation but last time I checked Facebook Chat did not. Such a shame.
Apparently Messenger does link with Facebook and Yahoo, but I don't see anything indicating a general federation. It occurs to me that IM services have established a twisted, mutant, incompletely-routed version of an IRC network amongst themselves. And as far as I can tell, they still haven't gotten group chat right...
I've read that there is an XMPP federation service [1], although having never touched it I don't know if there are any caveats.