jdev - 2019-12-19

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.

That makes no sense

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

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

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

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

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?

is this feasible

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

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

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

FCM and other push services are generally based on XMPP

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

Kev: I don't think we disagree.

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

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

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

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

Guus but isnt rest not feasible at scale?

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

would you say its better than xmpp?

You're asking if potatoes are better then bananas.

Potatios are obviously superior

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.

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.

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.

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

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

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

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

it's a trade-off.

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

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

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

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

Let's replace the web with UDP!

Oh wait that's already a thing 😞

sure, but take it as an example.

I hear the latest MQTT version now supports errors

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

QUIC! To the firewall rewriter!

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

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

don't over-optimize

Don't prematurely optimize

>Don't prematurely optimize that.

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

Anything is possible

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

You can always add another layer of abstraction

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

But you probably should know what problem you're solving

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.

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.

I got to pick up my kids from school.

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

cool, thanks man

np

I'm out. ttyl

flow, does Smack support Jingle streams?

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