jdev - 2019-12-19


  1. ghost

    Hi, I am new to XMPP. As of now I am planning to use either ejjaberd or mangooseIM. But the thing is I do not want my clients to directly talk to the XMPP server. I want a middleman between XMPP server and the clients' mobiles. So that even if we decide to move to other protocols like MQTT or etc, I can just change the code in the middleman layer without forcing the client to update the app. the design now will be commitmentless and backwards compatible. I am not able to find a decent way how to do this.

  2. MattJ

    That makes no sense

  3. Zash

    That's the kind of thing XMPP/Jabber was originally made for.

  4. MattJ

    You will still need a protocol between the clients and the "middleman layer", and that protocol won't change

  5. MattJ

    So you still have to pick one protocol or invent your own

  6. MattJ

    And Zash is right, XMPP was born out of a project that aimed to provide a "middleman layer" between clients and other protocols

  7. ghost

    but since xmpp takes care of all the needed information like last seen, message history etc, is there a way that I can get middle man to store all these information and whenver the actual client needs something, it can just call the rest api to get these information or I can use FCM or google push to push info from middle man to client?

  8. ghost

    is this feasible

  9. Zash

    Sounds like you're inventing XMPP over XMPP. Sure it's feasible.

  10. MattJ

    FCM and other push services are generally not that good for reliable/instant messaging

  11. Kev

    FWIW, I'm not at all sure that using something REST-ish for the last mile *is* stupid.

  12. Zash

    FCM and other push services are generally based on XMPP

  13. Zash

    Doesn't ejabberd or mongoose already have a REST API?

  14. Zash

    Kev: I don't think we disagree.

  15. Guus

    Openfire does. It seems to get a fair deal of usage.

  16. ghost

    yes it does but I thought using rest at scale is dumb, so I wanted to use push notifications

  17. Guus

    Primarily, it attracts web devs that are already familiar with applying REST solutions, but have no experience with XMPP

  18. ghost

    but still i ll have to maintain persistent connections when the app is active

  19. ghost

    Guus but isnt rest not feasible at scale?

  20. Guus

    Given that a good deal of the internet is REST based, I'd say it's pretty feasible.

  21. ghost

    would you say its better than xmpp?

  22. Guus

    You're asking if potatoes are better then bananas.

  23. Zash

    Potatios are obviously superior

  24. Guus

    my two cents: for IM solutions REST is far more of a generic approach. You'll have to provide all of the nuts and bolts for your features. XMPP has that covered.

  25. Guus

    a generic developer is more likely to be comfortable with an in-house created REST approach. Your project will start off very well. Then, you need to worry about things already covered by XMPP _and_ training additional developers to maintain your proprietary protocol/code base.

  26. Guus

    My advice would be to use the more specific tool for the job, even if it's harder to use. It will pay off in the long run.

  27. ghost

    The problem is that in the future if I decide to move from XMPP to MQTT or something, if i just go with XMPP, I will have to force the users to update the app when I move. But if i have a rest api layer beow my xmpp, then no matter what i change ym protocol to, the user can still use the same app

  28. Guus

    If in the future you have that decision to make, other things have gone wrong.

  29. Guus

    but, adding a layer of abstraction will fix that for you, to an extend.

  30. Guus

    but you'll have to worry about maintaining the introduced layer of abstraction.

  31. Guus

    it's a trade-off.

  32. Guus

    I'm a XMPP dev - guess where my preferences are 🙂

  33. Zash

    Moving from XMPP to MQTT makes no sense to me, why do people do that?

  34. Zash

    MQTT is a low-level protocol, XMPP is a high-level protocol

  35. MattJ

    MQTT isn't even a messaging protocol, so you still have to build in your own routing and semantics

  36. Zash

    Let's replace the web with UDP!

  37. Zash

    Oh wait that's already a thing 😞

  38. Guus

    sure, but take it as an example.

  39. MattJ

    I hear the latest MQTT version now supports errors

  40. ghost

    not necessarily, we might decide to move to an in house solution or may be to handle scale. As of now 2-3 million conc. users is what ejjaberd or Mangoose can handle, if we cross it we have to pay or build our own thing, so

  41. Ge0rG

    QUIC! To the firewall rewriter!

  42. Guus

    might as well have said 'matrix' or 'irc' instead of 'xmpp'

  43. Guus

    seriously, if you have 2 to 3 million users, you'll have to resources to rewrite whatever you want.

  44. Guus

    don't over-optimize

  45. Zash

    Don't prematurely optimize

  46. Guus

    >Don't prematurely optimize that.

  47. ghost

    Yes, i totally agree with that, I just wanted to know if this is possible and if its a good thing to do.

  48. Zash

    Anything is possible

  49. Guus

    If you want to expose very limited features provided by XMPP, it's worth considering.

  50. Zash

    You can always add another layer of abstraction

  51. Guus

    it'll allow you to attract a bigger number of developers.

  52. Zash

    But you probably should know what problem you're solving

  53. Guus

    if you want many features that live in XMPP, you'll quickly end up recreating XMPP in a different syntax. I'd not do that.

  54. ghost

    Guus : the thing is I am anyway hitting the api to transcribe and etc. So it would be a cleaner design if the same api can handle message sending and receiving.

  55. Guus

    I got to pick up my kids from school.

  56. Guus

    ghost I don't understand. If it makes sense to you: go for it.

  57. ghost

    cool, thanks man

  58. Guus

    np

  59. Guus

    I'm out. ttyl

  60. jonas’

    flow, does Smack support Jingle streams?

  61. jonas’

    (no need for A/V codec stuff, I want to transport custom real-time binary data)