blog.cpinto.net: blog.cpinto.net: One for the Jabber/XMPP community
vd
· 1 year ago
Recipient's server determines that if the server can store offline messages on behalf of the intended recipient; if not (e.g., because the recipient's offline message queue is full), the server returns a <service-unavailable/> error to the sender. Best Practices for Handling Offline Messages - http://www.xmpp.org/extensions/xep-0160.html Flexible Offline Message Retrieval - http://www.xmpp.org/extensions/xep-0013.html
ok, just clearing up that particular question: how would you scale offline message storage? :-)
Spike411
· 1 year ago
Really, why do you think that “offline message storage“ is any scalability issue or problem? (Why is it not a problem with current Twitter?)
I'd also suggest reading PubSub (Publish Subscribe) and PEP (Personal Eventing via PubSub) XEPs.
cpinto
· 1 year ago
I'm just trying to get the ball rolling, most of the questions up there refer to possible solutions I've heard or read about. My stance is that I know nothing of Twitter's internals and so prefer not to pass real judgment, but I have to admit that with the speculation surrounding it, it makes for a seriously engaging water cooler topic.
With regards to PubSub, I have my reservations that it would survive a large number of messages published by a very large number of nodes, at least without proper operations in place. But wouldn't that also solve it's current outages too?
vd
· 1 year ago
how would you scale offline message storage? GNBD (Global Network Block Device) and RHEL GFS (Global File System).
Steve Ivy
· 1 year ago
cpinto,
With xmpp, as long as the server your account is on support offline messaging, the data gets stored on your server, not the original service (ala Twitter).
cpinto
· 1 year ago
you are, of course, correct but: will you store pubsub notifications offline? if so, how would you do it if you had a usage spike. if not, how would you show a history of what has been happening to the user?
Steve Ivy
· 1 year ago
I'll admit some work does need to be done on where different levels of information in the system live, esp when discussing the application / xmpp server boundary. We've been discussing this for some time on the DiSo mailing list (http://groups/google.com/group/diso-project) and frankly, have not solved it yet to my satisfaction.
oscar
· 1 year ago
e, no meio disto tudo, para que serve o twitter? sim, para que serve, na realidade. a mim parece-me que é utterly useless...
All Comments
Best Practices for Handling Offline Messages - http://www.xmpp.org/extensions/xep-0160.html
Flexible Offline Message Retrieval - http://www.xmpp.org/extensions/xep-0013.html
You don't need one server, but rather a decent bot that (should) re-route the messages back to you.
http://groups.google.com/group/twitter-developm...
I'd also suggest reading PubSub (Publish Subscribe) and PEP (Personal Eventing via PubSub) XEPs.
refer to possible solutions I've heard or read about. My stance is that
I know nothing of Twitter's internals and so prefer not to pass real
judgment, but I have to admit that with the speculation surrounding it,
it makes for a seriously engaging water cooler topic.
With regards to PubSub, I have my reservations that it would survive a
large number of messages published by a very large number of nodes, at
least without proper operations in place. But wouldn't that also solve
it's current outages too?
GNBD (Global Network Block Device) and RHEL GFS (Global File System).
With xmpp, as long as the server your account is on support offline messaging, the data gets stored on your server, not the original service (ala Twitter).