Hey Bob,
On Thu, Jul 8, 2010 at 12:11 AM, Bob Wyman <[email protected]> wrote: > Julien Genestoux <[email protected]> wrote: > > > Indeed, the virtual feed approach is definetely our prefered > > option and the one we took for our track feeds. > > In your implementation, if your hub is processing a multi-entry feed and a > filter I specify matches only one of the potentially many updated entries in > the feed, what will you deliver to my call-back URL? Will you deliver the > entire feed or just the single entry that matched the filter? > No, just the matching entry. > > If an update to a single source feed matches many filters, it would seem > that you would need to deliver a fresh copy of the matched data for each of > the filters that matched since each filter defines a distinct virtual feed. > Is that correct? > yes, you would get a notification for each of the matched entry. The virtual feed approach means that basically if a subscriber was rebuilding the feed with the entry we'd sent him, each of the entries would belong to the url's 'logic'. Thanks, > > bob wyman > > On Wed, Jul 7, 2010 at 1:35 PM, Julien Genestoux < > [email protected]> wrote: > >> Indeed, the virtual feed approach is definetely our prefered option and >> the one we took for our track feeds. This way, they do not interfere in any >> way with the core protocol. >> >> >> On Wed, Jul 7, 2010 at 2:36 PM, Alexis Richardson <[email protected]>wrote: >> >>> Monica >>> >>> On Tue, Jul 6, 2010 at 11:45 PM, Monica Keller <[email protected]> >>> wrote: >>> > for hubs to provide >>> > "Virtual" Topic Urls. One example of this would be a firehose url with >>> > parameters for filtering. Also outside the scope of the spec would be >>> > for hubs to promote their virtual topic urls like Julien just did. >>> > >>> > This will be helpful as subscribers don't have to subscribe to raw >>> > topic urls one by one and can use the virtual or aggregated topic urls >>> > from the Service Provider >>> >>> I think "virtual topics" are a very good idea and a way to open the >>> door to (federatable) subscriptions for filtered streams of many >>> kinds. >>> >>> alexis >>> >>> >>> > Thoughts ? >>> > >>> > On Jul 1, 10:13 am, Julien Genestoux <[email protected]> >>> > wrote: >>> >> Hey, I don't mean to interrupt... but maybe this is part of the >>> conversation >>> >> : Superfeedr announced its track feature today : >>> http://blog.superfeedr.com/track/filter/xmpp/pubsubhubbub/track/ >>> >> >>> >> You can subscribe to keywords accross all the feeds that we host (more >>> than >>> >> 800 hubs now) or the feeds we have for the default hub. >>> >> >>> >> We want to get more filtering done... but it's obviously a quite >>> complex >>> >> task with high frequency publishing! >>> >> >>> >> Cheers, >>> >> >>> >> julien >>> >> >>> >> On Thu, Jul 1, 2010 at 7:04 PM, John Panzer <[email protected]> >>> wrote: >>> >> > A topic: URI scheme? >>> >> > -- >>> >> > John Panzer / Google >>> >> > [email protected] / abstractioneer.org < >>> http://www.abstractioneer.org/> / >>> >> > @jpanzer >>> >> >>> >> > On Thu, Jul 1, 2010 at 5:22 AM, Alexis Richardson < >>> [email protected]>wrote: >>> >> >>> >> >> On Wed, Jun 30, 2010 at 10:30 PM, Danny Briere < >>> [email protected]> >>> >> >> wrote: >>> >> >> > This is interesting, because I think we may be more concerned >>> with the >>> >> >> > "topic model" than the content filtering. So we have some >>> questions >>> >> >> > here: >>> >> >>> >> >> > 1) What is the current thinking / discussion / issues about the >>> topic >>> >> >> > model? I've searched the recent postings trying to find >>> references >>> >> >> > and more specifics....is there a URL I can look at? >>> >> >>> >> >> > 2) In the current spec, a topic is the same as a feed URL from >>> the >>> >> >> > publisher. But could the hub aggregate and / or segregate >>> content >>> >> >> > from incoming feed data and create its own topics? >>> >> >>> >> >> For my part, I would see that as a natural extension. How would >>> such >>> >> >> topics be created and managed? >>> >> >>> >> >> alexis >>> >> >>> >> >> > (For example, in item 2, our hub would aggregate press releases >>> and >>> >> >> > the segregate them based on industry / language / geography into >>> >> >> > multiple topics that users can subscribe to). >>> >> >>> >> >> > 3) Separately, we're also interested in being able to filter by >>> tagged >>> >> >> > field values to create filtered feeds. >>> >> >>> >> >> > -Danny >>> >> >>> >> >> > On Jun 29, 7:44 pm, Brett Slatkin <[email protected]> wrote: >>> >> >> >> On Tue, Jun 29, 2010 at 4:35 PM, Alexis Richardson < >>> >> >> [email protected]> wrote: >>> >> >> >> > On Wed, Jun 30, 2010 at 12:31 AM, Brett Slatkin < >>> [email protected]> >>> >> >> wrote: >>> >> >> >> >> On Tue, Jun 29, 2010 at 3:30 PM, Alexis Richardson >>> >> >> >> >> <[email protected]> wrote: >>> >> >> >> >>> On Tue, Jun 29, 2010 at 11:09 PM, Bob Wyman <[email protected]> >>> wrote: >>> >> >> >> >>>> Now that we've got substantial experience with topic-based >>> >> >> PubSubHubbub, >>> >> >>> >> >> >> >>> With all due respect - I don't think we have enough yet. >>> The spec >>> >> >> is >>> >> >> >> >>> still unstable. >>> >> >>> >> >> >> >> Specific wording aside, Alexis, it's a fine time to be >>> talking about >>> >> >> >> >> these ideas, right? >>> >> >>> >> >> >> > I don't wish to diss Bob's push in this direction. But I'd >>> like to >>> >> >> >> > see the topic model 'settle down' before looking at content. >>> I don't >>> >> >> >> > believe we are there yet. >>> >> >>> >> >> >> Gotcha. That's fine. I think everyone wants things to move >>> slowly. >>> >> >> >> This is the first I've seen of Bob's ideas in this direction and >>> I've >>> >> >> >> got to let it marinate in my brain a bit. But I'd imagine some >>> new >>> >> >> >> concerns about the existing spec may fall out of it, which is >>> probably >>> >> >> >> a good thing, even if we all collectively decide that they >>> should or >>> >> >> >> should not be in scope. >>> >> >>> >> >> >> -Brett >>> >> >> >
