Thank you so much, Ethan.
Imtiaz
----- Original Message -----
From: "Ethan Jewett" <[email protected]>
To: <[email protected]>
Sent: Saturday, August 28, 2010 7:14 PM
Subject: Re: ESME-170 - PubSubHubub
Dick,
Any of the above. If there is a use case it should not be too
difficult to keep one or more timestamped counters on the feed.
Imtiaz,
Sounds good to me. I'm totally in favor of charging ahead in branches.
Ethan
On Saturday, August 28, 2010, Richard Hirsch <[email protected]>
wrote:
On Sat, Aug 28, 2010 at 10:29 AM, Ethan Jewett <[email protected]>
wrote:
I forgot to address the "inundated with messages" problem you bring
up. I actually think this is not a problem, even though it appears to
be an issue. Admittedly, a user could really mess up their timeline
and have everybody unsubscribe from them, but with the capability to
put RSS feed items into specific pools and tags I can see use cases
for a huge deluge of messages into a limited pool, especially for
users that are managed by technical systems via the API. For example,
a CRM system using ESME may actually be interested in seeing every
feed item PuSHed from a Google Buzz tracking feed.
We could always have a configuration option to rate limit the ability
of RSS actions to create messages. We could definitely add that if it
became a problem.
Would this limit be system-wide or user-specific?
Does that address your concern? Was there something that I'm not
thinking of?
Ethan
On Sat, Aug 28, 2010 at 4:51 AM, Imtiaz Ahmed H E <[email protected]>
wrote:
However,
If a feed PuSHes too often Esme may be inundated with messages. So,
instead
of what Ethan concurs with below, should the user have the option to
poll
'every 5 mins' or so even if the feed supports PuSH ?
Also, a feed may support PuSH but the hub may breakdown. In that case
should
the user be reverted to say, a default of, 'every 5 mins' ?
Maybe we should have two kinds of filter tests.
1. every n mins
2. onpush default every n mins
PubSubHubub will be used only in 2 above, reverting to every n mins if
the
feed's hub breaks down (fails)..
In 1 above, only polling will be done even if the feed supports PuSH.
Let me know if this sounds okay...
Imtiaz
----- Original Message ----- From: "Ethan Jewett" <[email protected]>
To: <[email protected]>
Sent: Wednesday, August 18, 2010 10:05 PM
Subject: Re: ESME-170 - PubSubHubub
Hi Imtiaz,
I completely agree. If we need to revamp the filter syntax to make
this more clear, we can do that after the PuSH functionality is
already in place.
Thanks!
Ethan
On Wed, Aug 18, 2010 at 7:38 AM, Imtiaz Ahmed H E
<[email protected]>
wrote:
Ethan,
After some initial thoughts otherwise about this, I now feel, for an
RSS/ATOM feed that PuSHes ( PuSH is an acronym for PubSubHubub) we
should
just ignore any test (filter) whatsoever and update the user's
messages
whenever a feed update is PuSHed to ESME.
Let me know if otherwise...
Imtiaz
----- Original Message ----- From: "Imtiaz Ahmed H E"
<[email protected]>
To: <[email protected]>
Sent: Tuesday, August 17, 2010 12:20 PM
Subject: Re: ESME-170 - PubSubHubub
Well, I need to know all the possible kinds of tests (filters
conditions)
that make sense for an RSS/ATOM action.
Imtiaz
----- Original Message ----- From: "Vassil Dichev"
<[email protected]>
To: <[email protected]>
Sent: Tuesday, August 17, 2010 8:19 AM
Subject: Re: ESME-170 - PubSubHubub
It's the kind of filter condition which makes the best sense for
this
action, at least. What do you want to do?
Vassil
On Tue, Aug 17, 2010 at 5:30 AM, Imtiaz Ahmed H E
<[email protected]>
wrote:
Probably can figure this out, but would someone oblige and tell
me...
Is
every nn mins rss-url
the only form/kind of an rss/atom b
