21–30 of 41 posts
Now, I hope the other protocols I use such as Skype, Steam (And I guess Origin too) would follow suit. I would love to know when my friends are playing games, without having to be tied to either wine, virtualbox, or my gaming PC or yet another client.
Earlier quoted context omitted.
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...
What's wrong with XMPP multi-user chat? And I don't understand your argument of "incompletely-routed", especially if compared to IRC. imho XMPP federation is much more powerful concept than IRC networking.
I was speaking more generally than XMPP. I don't know the fundamental causes, but I haven't seen group/multi-user chat work reliably in years -- I think the last time I did, everybody was on ICQ using official clients.
The problems I have encountered are:
1) Group chats just don't start.
2) Not everyone can see/"hear" everyone else.
3) Rarely, #2 starting and stopping randomly for people.
I've seen these behaviors on chats with as few as 3 people, up to 8ish (don't think I've ever gone higher than that).
I doubt the protocols are fundamentally broken in this regard, I assume I'm encountering implementation bugs, but they seem to be pervasive.
> And I don't understand your argument of "incompletely-routed", especially if compared to IRC.
"incompletely-routed" may not be a good phrase to use here, least of all because not many people "get" IRC anymore.
IRC networks eventually stabilized into a model whereby there was network-wide coordination of routing. Every server on a network can talk to every other server, and there is no leakage outside of the network. You know what you're getting when you connect to one of the major networks. With IM, links may be established between A and B, and B and C, but not A and C.
> imho XMPP federation is much more powerful concept than IRC networking.
I would absolutely agree in so far as the intent of XMPP federation goes. In practice, there are two problems:
1) Some IM providers intentionally cripple it (e.g. Facebook).
2) Not all IM providers use XMPP in the first place. Even some of the ones that make available a limited XMPP interface don't actually base their services off of it (Facebook, Microsoft).
It's important to realize that IM is not the same as XMPP, so when I say "IM", I mean "IM", not the XMPP subclass. :)
From a user point of view Microsoft butchered Messenger a long time ago. That's why Facebook killed it very easily. First the official client (which I never stoud btw) became shittier with each release. Then they made that (very very) bad Facebook copy and forced users to display their real name instead of nicknames. Moreover Messenger suffers from protocol version fragmentation. Features in alternative clients are r…
I wonder if this is because Microsoft is becoming better and better at embracing open source when it sees a business advantage to do so, or if it's simply a last-ditch effort to keep Messenger alive as more and more people use it less frequently or not at all because the likes of smartphones, apps, and Facebook (Chat) are becoming more widely adopted.
I'm guessing it's the former. In the past 2 weeks I've heard MS submit a patch to Redis, they've helped bring Node.js to Windows, Phil Haack joined GitHub primarily to bring C# into that open source community's limelight,... and now this. Seems to me like someone's been pushing the open source agenda within Microsoft.
Signed, A kinder, gentler Death Star
I was involved with the effort [to avoid] standardizing instant messaging back in 1999-2000. One of the products the company I was with at the time was offering was an instant messenger (with a twist that is not important for this story), so we tried to support all the prevailing protocols of the time (AIM, ICQ, MSN Messenger, Yahoo Messenger, PowWow, IRC, ... I don't even remember). And I was eagerly following the i…
As someone deeply concerned with real-world operation of systems, I find your removal of the "claim" distressing. It is true that developers routinely create very poorly thought out protocols that have massive overhead, but it is far from good practice, and anyone who tries to foist such a disaster on me for any reason other than business-critical interoperability will be SOL. I simply will not deploy it, they will h…
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 other transfers. I think you have to think pretty hard to come up with a situation where you'd really want to use XMPP if only it wasn't for the overhead. Huge amounts of small messages exchanged between embedded devices, maybe?
Incidently, your message had 722 characters, the whole page had 4.83 kb. Pretty bad overhead, and of course HN is extremely frugal. I'm sure Twitter is much much worse. Apples and oranges, I know.
Does that also mean that I can send messages to Messenger from other XMPP networks (and also the other way around)?
I was involved with the effort [to avoid] standardizing instant messaging back in 1999-2000. One of the products the company I was with at the time was offering was an instant messenger (with a twist that is not important for this story), so we tried to support all the prevailing protocols of the time (AIM, ICQ, MSN Messenger, Yahoo Messenger, PowWow, IRC, ... I don't even remember). And I was eagerly following the i…
As someone deeply concerned with real-world operation of systems, I find your removal of the "claim" distressing. It is true that developers routinely create very poorly thought out protocols that have massive overhead, but it is far from good practice, and anyone who tries to foist such a disaster on me for any reason other than business-critical interoperability will be SOL. I simply will not deploy it, they will h…
Earlier quoted context omitted.
As someone deeply concerned with real-world operation of systems, I find your removal of the "claim" distressing. It is true that developers routinely create very poorly thought out protocols that have massive overhead, but it is far from good practice, and anyone who tries to foist such a disaster on me for any reason other than business-critical interoperability will be SOL. I simply will not deploy it, they will h…
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…
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 magnitude. As it happens, that is also the range I commonly get from people who have just "designed" a protocol with zero thought.
> I think you have to think pretty hard to come up with a situation where you'd really want to use XMPP if only it wasn't for the overhead. Huge amounts of small messages exchanged between embedded devices, maybe?
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.
> Incidently, your message had 722 characters, the whole page had 4.83 kb.
I don't have to design, implement, or deploy websites, and consider the entire model quite broken for communications, so the comparison changes my opinion not at all.
Earlier quoted context omitted.
As someone deeply concerned with real-world operation of systems, I find your removal of the "claim" distressing. It is true that developers routinely create very poorly thought out protocols that have massive overhead, but it is far from good practice, and anyone who tries to foist such a disaster on me for any reason other than business-critical interoperability will be SOL. I simply will not deploy it, they will h…
Considering a single TCP segment will probably be used with or without XML bloat, is that really important nowadays? Not that it isn't bad practice (something in e.g. Protocol Buffers should probably be used), but to refuse to use it seems harsh.
I know there's this tendency to dismiss bandwidth these days, but it's quite misguided. You literally wouldn't believe the quotes we got in Taiwan -- I thought there was some major misunderstanding until I got there and actually sat down with the network team at the telecom provider.