| 2012-06-26 11:45:16 |
Dominique Guardiola |
description |
Hi Ivan
This is not a bug report, rather a question
We're thinking of using subhub for several django sites that need to synchronize their data in "real-time"
It's not only articles, but objects that are passed as a JSON-LD payload in the <summary> XML tag.
Your concept of "private" hub fits well in our project too
We tested before a hosted hub (SuperFeeder) and when pinging the hub to tell it there was new content, we only passed the feed URL (the "topic") and the hub was then in charge of notifying suscribers, depending probably on a diff with the previous version of the feed.
If I understand wekk the code,
- One DistributionTask is created for each entry and for each suscriber
- when processed, the notifications are grouped to be delivered together to the suscriber callback URL
does it means that there's no use for the suscriber to have a different callback URL for each subscription, as all their subscriptions will be delivered together ?
We currently use the djpubsubhubbub module for the suscriber part, and there's a unique callback URL per subscription:
https://bitbucket.org/petersanchez/djpubsubhubbub/src/953e9209d65a/djpubsubhubbub/views.py#cl-30
(and at first, we found it strange) |
Hi Ivan
This is not a bug report, rather a question
We're thinking of using subhub for several django sites that need to synchronize their data in "real-time"
It's not only articles, but objects that are passed as a JSON-LD payload in the <summary> XML tag.
Your concept of "private" hub fits well in our project too
We tested before a hosted hub (SuperFeeder) and when pinging the hub to tell it there was new content, we only passed the feed URL (the "topic") and the hub was then in charge of notifying suscribers, depending probably on a diff with the previous version of the feed.
If I understand well your code,
- One DistributionTask is created for each entry and for each suscriber
- when processed, the notifications are grouped to be delivered together to the suscriber callback URL
does it means that there's no use for the suscriber to have a different callback URL for each subscription, as all their subscriptions will be delivered together ?
We currently use the djpubsubhubbub module for the suscriber part, and there's a unique callback URL per subscription:
https://bitbucket.org/petersanchez/djpubsubhubbub/src/953e9209d65a/djpubsubhubbub/views.py#cl-30
(and at first, we found it strange) |
|
