-
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.
-
MattJ
That makes no sense
-
Zash
That's the kind of thing XMPP/Jabber was originally made for.
-
MattJ
You will still need a protocol between the clients and the "middleman layer", and that protocol won't change
-
MattJ
So you still have to pick one protocol or invent your own
-
MattJ
And Zash is right, XMPP was born out of a project that aimed to provide a "middleman layer" between clients and other protocols
-
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?
-
ghost
is this feasible
-
Zash
Sounds like you're inventing XMPP over XMPP. Sure it's feasible.
-
MattJ
FCM and other push services are generally not that good for reliable/instant messaging
-
Kev
FWIW, I'm not at all sure that using something REST-ish for the last mile *is* stupid.
-
Zash
FCM and other push services are generally based on XMPP
-
Zash
Doesn't ejabberd or mongoose already have a REST API?
-
Zash
Kev: I don't think we disagree.
-
Guus
Openfire does. It seems to get a fair deal of usage.
-
ghost
yes it does but I thought using rest at scale is dumb, so I wanted to use push notifications
-
Guus
Primarily, it attracts web devs that are already familiar with applying REST solutions, but have no experience with XMPP
-
ghost
but still i ll have to maintain persistent connections when the app is active
-
ghost
Guus but isnt rest not feasible at scale?
-
Guus
Given that a good deal of the internet is REST based, I'd say it's pretty feasible.
-
ghost
would you say its better than xmpp?
-
Guus
You're asking if potatoes are better then bananas.
-
Zash
Potatios are obviously superior
-
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.
-
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.
-
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.
-
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
-
Guus
If in the future you have that decision to make, other things have gone wrong.
-
Guus
but, adding a layer of abstraction will fix that for you, to an extend.
-
Guus
but you'll have to worry about maintaining the introduced layer of abstraction.
-
Guus
it's a trade-off.
-
Guus
I'm a XMPP dev - guess where my preferences are 🙂
-
Zash
Moving from XMPP to MQTT makes no sense to me, why do people do that?
-
Zash
MQTT is a low-level protocol, XMPP is a high-level protocol
-
MattJ
MQTT isn't even a messaging protocol, so you still have to build in your own routing and semantics
-
Zash
Let's replace the web with UDP!
-
Zash
Oh wait that's already a thing 😞
-
Guus
sure, but take it as an example.
-
MattJ
I hear the latest MQTT version now supports errors
-
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
-
Ge0rG
QUIC! To the firewall rewriter!
-
Guus
might as well have said 'matrix' or 'irc' instead of 'xmpp'
-
Guus
seriously, if you have 2 to 3 million users, you'll have to resources to rewrite whatever you want.
-
Guus
don't over-optimize
-
Zash
Don't prematurely optimize
-
Guus
>Don't prematurely optimize that.
-
ghost
Yes, i totally agree with that, I just wanted to know if this is possible and if its a good thing to do.
-
Zash
Anything is possible
-
Guus
If you want to expose very limited features provided by XMPP, it's worth considering.
-
Zash
You can always add another layer of abstraction
-
Guus
it'll allow you to attract a bigger number of developers.
-
Zash
But you probably should know what problem you're solving
-
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.
-
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.
-
Guus
I got to pick up my kids from school.
-
Guus
ghost I don't understand. If it makes sense to you: go for it.
-
ghost
cool, thanks man
-
Guus
np
-
Guus
I'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)