ghostHi, 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.
MattJThat makes no sense
ZashThat's the kind of thing XMPP/Jabber was originally made for.
MattJYou will still need a protocol between the clients and the "middleman layer", and that protocol won't change
MattJSo you still have to pick one protocol or invent your own
MattJAnd Zash is right, XMPP was born out of a project that aimed to provide a "middleman layer" between clients and other protocols
ghostbut 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?
ghostis this feasible
ZashSounds like you're inventing XMPP over XMPP. Sure it's feasible.
MattJFCM and other push services are generally not that good for reliable/instant messaging
KevFWIW, I'm not at all sure that using something REST-ish for the last mile *is* stupid.
ZashFCM and other push services are generally based on XMPP
ZashDoesn't ejabberd or mongoose already have a REST API?
ZashKev: I don't think we disagree.
GuusOpenfire does. It seems to get a fair deal of usage.
ghostyes it does but I thought using rest at scale is dumb, so I wanted to use push notifications
GuusPrimarily, it attracts web devs that are already familiar with applying REST solutions, but have no experience with XMPP
ghostbut still i ll have to maintain persistent connections when the app is active
ghostGuus but isnt rest not feasible at scale?
GuusGiven that a good deal of the internet is REST based, I'd say it's pretty feasible.
ghostwould you say its better than xmpp?
GuusYou're asking if potatoes are better then bananas.
ZashPotatios are obviously superior
Guusmy 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.
Guusa 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.
GuusMy 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.
ghostThe 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
GuusIf in the future you have that decision to make, other things have gone wrong.
Guusbut, adding a layer of abstraction will fix that for you, to an extend.
Guusbut you'll have to worry about maintaining the introduced layer of abstraction.
Guusit's a trade-off.
GuusI'm a XMPP dev - guess where my preferences are 🙂
ZashMoving from XMPP to MQTT makes no sense to me, why do people do that?
ZashMQTT is a low-level protocol, XMPP is a high-level protocol
MattJMQTT isn't even a messaging protocol, so you still have to build in your own routing and semantics
ZashLet's replace the web with UDP!
ZashOh wait that's already a thing 😞
Guussure, but take it as an example.
MattJI hear the latest MQTT version now supports errors
ghostnot 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
Ge0rGQUIC! To the firewall rewriter!
Guusmight as well have said 'matrix' or 'irc' instead of 'xmpp'
Guusseriously, if you have 2 to 3 million users, you'll have to resources to rewrite whatever you want.
ZashDon't prematurely optimize
Guus>Don't prematurely optimize
ghostYes, i totally agree with that, I just wanted to know if this is possible and if its a good thing to do.
ZashAnything is possible
GuusIf you want to expose very limited features provided by XMPP, it's worth considering.
ZashYou can always add another layer of abstraction
Guusit'll allow you to attract a bigger number of developers.
ZashBut you probably should know what problem you're solving
Guusif you want many features that live in XMPP, you'll quickly end up recreating XMPP in a different syntax. I'd not do that.
ghostGuus : 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.
GuusI got to pick up my kids from school.
Guusghost I don't understand. If it makes sense to you: go for it.
ghostcool, thanks man
GuusI'm out. ttyl
jonas’flow, does Smack support Jingle streams?
jonas’(no need for A/V codec stuff, I want to transport custom real-time binary data)