3 ms·

>> "simple to implement" I haven't looked into wave in much detail, but being based on XMPP is by no means simple. XMPP is the most over engineered over comple

by axod 17y ago

>> "simple to implement" I haven't looked into wave in much detail, but being based on XMPP is by no means simple. XMPP is the most over engineered over complex verbose ridiculous protocol ever invented. There were several people saying Jabber would kill IRC years ago. I'm reserving judgement on wave personally, I'm skeptical it'll be able to make a dent. Technically awesome, but I'm not convinced yet it solves real problems users have.

calambrac 17y ago
You've never seen SOAP and WS-*, then, I guess?
- andrewf 17y ago
  The best WS-* is WS-I, which lays out the ways in which you should use SOAP and the rest of WS-* if you actually want to talk to anyone.
jmillikin 17y ago
>> There were several people saying Jabber would kill IRC years ago Who? I doubt anybody knowledgeable would claim that Jabber would kill IRC, since the two protocols serve largely different purposes. Jabber has killed off most of the smaller closed IM networks, and even the large ones are smaller than they once were. As for the claimed difficulty of implementing XMPP, I'd like to see some more references on that. I'm writing an XMPP library now, and it doesn't seem particularly difficult. With only an hour or two of work, it can connect securely to 3rd-party servers and act as a useful bot. With a bit more work, I'm sure it could be a production-quality library. Furthermore, the proliferation of implementations for various languages and platforms suggests that the barrier to entry for an XMPP library is rather low.
- axod 17y ago
  From a previous thread on XMPP: http://news.ycombinator.com/item?id=426581 http://news.ycombinator.com/item?id=426581 Even the specs for XMPP+extensions seem to be written in XML, running to thousands of pages due to the overly-general-underly-practical nature.
  - jmillikin 17y ago
    Yes, it's difficult to establish a secure connection. This is due to the nature of security in general, and is not inherent to XMPP. If you want to just write plain-text messages without authentication, you could do so with netcat. If you want to use digest-auth and SSL, obviously the client and server will be more complicated. Many servers will outright refuse to authenticate a connection unless it's using TLS and digest auth, which is an excellent idea. I don't think expecting any modern protocol to support typing commands in by hand over netcat/telnet is reasonable.
    - axod 17y ago
      $ openssl s_client -connect irc.mibbit.com:6697 Works for me... In comparison, it's not possible to use a general tool to do anything like this with XMPP, because it's all wrapped in endless XML complexity.
      - jmillikin 17y ago
        You've yet to state how using XML as a serialization layer introduces any additional complexity into XMPP. Your example doesn't support TLS upgrading, forcing TLS and plaintext connections to be handled on separate ports. You also ignore authentication and authorization, which are much more important than merely opening an encrypted socket to some arbitrary server. IRC is a nice protocol for things that don't matter, but it's utterly unsuitable for applications that require security or features beyond "send text and hope some client receives it, eventually".
        axod 17y ago
        It's about 3 times the bandwidth for a start. I agree @TLS, authorization etc, but often those just aren't a priority. email is often used without any security but it's far from something that "doesn't matter". IM protocols have barely any security, yet we all use them.
        jmillikin 17y ago
- wooster 17y ago
  I wrote a Jabber client for OS X public beta back in 2000. It was a horrendous pain in the ass. I was also on the IMPP working group list for a few years. The big standout problem with XMPP is "XML streaming", which is fairly difficult to handle tersely, correctly, securely, and reliably. Mostly this is because parsing streaming XML (using, say, SAX) usually involves writing a lot of one-off code. Most of that code is just going to be making sure your messages correspond to the spec, don't start getting too deep, are complete, etc. Then there's the out of band data stuff, which at the time, was basically undefined. Now, it's defined, in a whole lot of specs. Then there's RTF, which is used by several Windows clients as a message format. That's what I remember, at least, and skimming the current RFC's suggests things haven't changed much.

by axod 17y ago

calambrac 17y ago

You've never seen SOAP and WS-*, then, I guess?

andrewf 17y ago
The best WS-* is WS-I, which lays out the ways in which you should use SOAP and the rest of WS-* if you actually want to talk to anyone.

jmillikin 17y ago

>> There were several people saying Jabber would kill IRC years ago Who? I doubt anybody knowledgeable would claim that Jabber would kill IRC, since the two protocols serve largely different purposes. Jabber has killed off most of the smaller closed IM networks, and even the large ones are smaller than they once were. As for the claimed difficulty of implementing XMPP, I'd like to see some more references on that. I'm writing an XMPP library now, and it doesn't seem particularly difficult. With only an hour or two of work, it can connect securely to 3rd-party servers and act as a useful bot. With a bit more work, I'm sure it could be a production-quality library. Furthermore, the proliferation of implementations for various languages and platforms suggests that the barrier to entry for an XMPP library is rather low.

axod 17y ago
From a previous thread on XMPP: http://news.ycombinator.com/item?id=426581 http://news.ycombinator.com/item?id=426581 Even the specs for XMPP+extensions seem to be written in XML, running to thousands of pages due to the overly-general-underly-practical nature.
- jmillikin 17y ago
  Yes, it's difficult to establish a secure connection. This is due to the nature of security in general, and is not inherent to XMPP. If you want to just write plain-text messages without authentication, you could do so with netcat. If you want to use digest-auth and SSL, obviously the client and server will be more complicated. Many servers will outright refuse to authenticate a connection unless it's using TLS and digest auth, which is an excellent idea. I don't think expecting any modern protocol to support typing commands in by hand over netcat/telnet is reasonable.
  - axod 17y ago
    $ openssl s_client -connect irc.mibbit.com:6697 Works for me... In comparison, it's not possible to use a general tool to do anything like this with XMPP, because it's all wrapped in endless XML complexity.
    - jmillikin 17y ago
      You've yet to state how using XML as a serialization layer introduces any additional complexity into XMPP. Your example doesn't support TLS upgrading, forcing TLS and plaintext connections to be handled on separate ports. You also ignore authentication and authorization, which are much more important than merely opening an encrypted socket to some arbitrary server. IRC is a nice protocol for things that don't matter, but it's utterly unsuitable for applications that require security or features beyond "send text and hope some client receives it, eventually".
      - axod 17y ago
        It's about 3 times the bandwidth for a start. I agree @TLS, authorization etc, but often those just aren't a priority. email is often used without any security but it's far from something that "doesn't matter". IM protocols have barely any security, yet we all use them.
        jmillikin 17y ago
wooster 17y ago
I wrote a Jabber client for OS X public beta back in 2000. It was a horrendous pain in the ass. I was also on the IMPP working group list for a few years. The big standout problem with XMPP is "XML streaming", which is fairly difficult to handle tersely, correctly, securely, and reliably. Mostly this is because parsing streaming XML (using, say, SAX) usually involves writing a lot of one-off code. Most of that code is just going to be making sure your messages correspond to the spec, don't start getting too deep, are complete, etc. Then there's the out of band data stuff, which at the time, was basically undefined. Now, it's defined, in a whole lot of specs. Then there's RTF, which is used by several Windows clients as a message format. That's what I remember, at least, and skimming the current RFC's suggests things haven't changed much.