So I'll chime in here because this is near and dear to my heart. I too think that PubSubHubbub is a great technology but there are a lot of business issues to take this to the next level. The question is what is in the hub and what is in the end server/subscriber domain. For my application, which is in the Marketing space, I am solving this on the endpoints because this is largely the way that today's business feeds are set up. Typically you subscribe to approximately what you want to get from a feed and you expect to have to slice and dice the data in some fashion. Unless you are paying for a fully customized feed, you generally have to merge, purge and otherwise groom content. So I'm not so concerned with trying to give someone a perfect feed; rather, provide them with the information they need to make good decisions over what they want to get.
For this, we're pushing for embedded marketing-related tags, so you could know that a bit of content is a white paper or an event or a new release or whatever. So we see this as a necessary other half of the equation -- without embedded tags, the information is near worthless. It's like the impact that Google Search has had before and after its vertical categorization into News, Video, etc. The problem we have had is that for embedded tags to really have an effect you need some players behind you to step up and say they'll "read" the tags. I've been trying to find people in Google, Bing, Yahoo etc. who want to work to define these tags (I have such proposed definitions created), but am struggling to get to the right people -- I'll continue to hunt. In the end, I would offer that to try to do this in the hub starts to sound a lot like the XML routing space that already exists and any subscribing server can handle on their own. I'm not sure it needs to be specifically in this hub spec. But I'm less a technologist than most on this list. Danny On Aug 24, 4:59 am, Robin Boast <[email protected]> wrote: > Dear all, > > I think that Niranjan's points are important, especially point 1. Coming > from very large data repositories, I have found that PSHB still seems to > think on the small scale, e.g. relatively small directed feeds. However, the > world I work in, which is perfect for PSHB, is large and dynamic datasets. > What my very diverse users want are feeds that they can filter. Now I am > sceptical that metadata is the way forward here, but some form of > subscriber-set filters would be essential when the feeds get very big. > > Best, > > Robin > > On 23 August 2010 18:00, Niranjan <[email protected]> wrote: > > > > > Hi, > > > Had a few thoughts on potential add-ons. (with business usecases in > > mind). > > > These definitely fall outside the basic spec and may not be as > > technically sound, and that's why i would appreciate some critique. > > > 1. Can Hubs be engineered to understand the message-content they > > handle? If hubs are made content-aware (atleast through meta- > > information/tags if not the entire content, keeping in mind security > > constraints), they could double up as yellow-pages. This would enable > > them to project themselves on their "reach" to other hubs in a > > distributed topology, or to publishers so that publishers put their > > best foot forward, offerings-wise, before linking with a given hub. > > Subscribers could further state their interest in topic-categories on > > Hubs and this would give further useful information to potential > > publishers to adapt their business offerings accordingly. > > > 2. Is there any activity in the pipeline to evolve a standard set of > > objects per business, now that there are (widely used)Hubs? Are Hubs a > > nice place to enforce standards in business objects that pass through > > them? (having a series of "superset" business objects, with > > standardized field definitions per business, would reduce so much > > effort in basic data-mapping, later in the ESBs.) > > > 3. Is there a directory to discover Hubs? Alternately, instead of > > having exclusive directories, why not place a mini-directory inside > > each hub/select hubs pointing to local hubs? This is analogous to > > asking around for directions on the way to a place and leaving a trail > > of knowledge on the way, rather than reaching a centralized board > > displaying directions. If there were knowledge-based Hubs, the > > knowledge-bank of each hub would keep increasing this way. > > > The gist is -- can one add a business dimension to this? > > > Regards, > > Niranjan > > -- > =================== > Dr. Robin Boast > Curator for World Archaeology > Affiliated Research Scholar, History and Philosophy of Science > +44 (0)1223 333515 > [email protected] > blog:http://rescite.blogspot.com/ > GWave: [email protected] > GTalk: robinboast > Buzz: Robin Boast > > MAA Museum of Archaeology & Anthropology > University of Cambridge > Downing Street, > Cambridge, UK CB2 3DZhttp://maa.cam.ac.uk/
