mickael said:

mickael

It seem the concept of using XMPP to replace the web is taking off. We XMPP guys are promoting of since 7 years.

5 months, 1 week ago in Home, Paris, France.

12 comments so far

  • ralphm

    Tsk. Replacing the web has never been the goal, I would say. Complementing it, though, you bet! HTTP is being bent in every direction to make it do thing it wasn't designed for, and XMPP seems to be a natural replacement in those areas. But HTTP still has a strong set of use cases it excels in.

    5 months, 1 week ago by ralphm.

  • tommi

    An intriguing topic, this.

    5 months, 1 week ago by tommi.

  • mickael

    Yes, I volontary pushed the idea very far. Xmpp is not made to deal with rendering for example. However, it has been designed from the beginning as an interface to services. A way to mix humans and applications in the same workflow.

    5 months, 1 week ago by mickael.

  • melo

    I don't believe XMPP will ever replace HTTP for pull-style interactions. It just fails miserably with large content for example.

    For push-style interactions, or presence-aware interactions, its unbeatable right now.

    1 week, 5 days ago by melo.

  • ralphm

    @melo: Quite a backlog of Jaiku reading you have there.

    1 week, 5 days ago by ralphm.

  • mickael

    @melo: I agree for large content, but even for large blog content HTTP is not even ideal.

    1 week, 5 days ago by mickael.

  • ralphm

    @mickael: huh what? How is HTTP not adequate for large blog content, exactly?

    1 week, 5 days ago by ralphm.

  • melo

    @ralphm: just found this thread :)

    @mickael: that ship has sailed in my opinion. With HTTP1.1, chunked encoding, and byte range support, HTTP is actually quite good.

    But maybe you are complaining about RSS/Atom pooling. If yes, then sure, HTTP pooling sucks, because that's a fake push. But I would prefer to:

    1. get notified via XMPP of new content;
    2. fetch via HTTP.

    Done.

    1 week, 5 days ago by melo.

  • mickael

    yes, suppose you publish an infinite content (streaming), it is becoming akward. and to share a Gb content it will not be my protocol of choice

    1 week, 5 days ago by mickael.

  • melo

    You are always pushing an infinite stream, but clients don't need to pull every item. Maybe the teaser in the notification is enough for me not to pull the rest.

    HTTP can be per item. You just fetch the items that you want.

    Bad architecture of current Blog systems, should not be blamed on HTTP...

    1 week, 5 days ago by melo.

  • dwd

    Well, for streaming, no, HTTP is not ideal, but unless we can get multicast deployed, there's little alternative. Likewise, you could easily build a better protocol than HTTP - HTTP sucks - but the trouble is that you can't build one sufficiently better for HTTP's core and close use-cases that people actually switch.

    1 week, 5 days ago by dwd.

  • ralphm

    Ah, but infinite content != blog content. If you want streaming, we have other protocols for that. Like RTP.

    As for sharing a GiB file, sure you can use other protocols for that, but I maintain that HTTP can handle that quite nicely. Unless you mean other properties that come with the use of HTTP, like its TCP binding and it not working nicely with firewalls etc. Then yeah, other protocols might be better.

    1 week, 5 days ago by ralphm.

Sign in to add a comment