Consider PuSH about tent.io HOT 14 CLOSED

Not to mention, PuSH does not prohibit the originating node to also be a hub, which is equivalent to the basic model proposed. It's only more flexible for other situations.

from tent.io.

The upcoming 0.4 spec seems to be completely compatible with the Tent protocol:

• Subscribers / publishers for the user model
• Support for arbitrary content types, not tied to RSS / Atom anymore
• Support for subscription validation, very useful for people with private profiles

Tent could base its core publish/subscribe features on PuSH and extend it by specifying the formats exchanged (user profiles, notifications, status updates, etc.).

The spec is close to a stable state and can be read at http://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html. Pretty sure the people at https://github.com/pubsubhubbub/PubSubHubbub would be happy to help if needed :)

from tent.io.

PuSH is so good, clean and simple. Good it doesn't require Atom. I'm looking forward to implementing these changes in my own projects. I think tent.io's goals are better met through leveraging PuSH.

from tent.io.

+1

from tent.io.

At least, a single notification for every user on the same tent provider, would be better.
The tent server have to notify each tent provider conserne by the post but only once each.

from tent.io.

Why was this issue closed apparently without any comment by the tent.io developers for their rationale?

from tent.io.

Github issue inbox bankruptcy?

from tent.io.

You know. It might help them with their scaling problems since they seem to be maintaining a queue of published posts fairly naively: https://tent.is/blog/october-1-outage via code 'fix': tent/tentd@2c57d50

Guess what a background queue for publishing is! That's PuSH but with the hub process being hosted on the same node as the publisher. Something I noted is possible with PuSH. If they want to scale further, they'll have to off-load some of the queue on to other servers... oh wait. That's the rest of PuSH. It's like somebody already thought of this.

They do something naive. We recommend something full-featured. They close the issue. Seems clear to me. The best argument is none.

from tent.io.

@danielsiders care to elaborate on reasoning? PubSubHubBub is almost perfect for Tent. The only problem is that its Atom/RSS only, but for usage within tent its easy to modify the spec in just that point for the content types.

from tent.io.

@beberlei see my comment about content types: #7 (comment)

from tent.io.

@brutasse oh thanks for pointing it out, i knew i read about PUSH 0.4 somewhere before, but couldnt remember. Awesome :)

from tent.io.

I'm not very familiar with PuSH, but reading the spec, why would the Tent protocol need to integrate it, rather than leave it as an implementation detail of how servers do pub-sub?

from tent.io.

@mwanji Part of the PuSH spec is I think about how a client subscribes and how a service delegates where the subing is handled.

from tent.io.

@alexwright In the discovery section, it says that publishers must return a Link header with rel=hub pointing to the topic URL that can be subscribed to. So it seems to me that it is up to Tent servers to provide that header and up to clients to know how to handle it, but that it is itself outside the Tent spec.

I agree with everyone else that it sounds like a nice way to scale notifications.

from tent.io.