I don't want to overburden this list with advertorial commentary, but note that:
* The more features are requested at the hub, the more users move away from 'pure' spec implementations, towards 'value adding' products and services like rabbithub/rabbitmq and superfeedr to name two. * Try as we might, providers of the latter *are* adding a 'management overhead' * I'm sure that *any* sensible messaging broker or service could make xml based routing work with PuSH; I know that we can and it's *not hard* A big question for this community list is this: what needs to be in the PuSH spec? what can be left to implementers? Finally: it is great to see the level of sophistication in messaging creep up here. That shows real world use. But let's also remember an axiom of the spec: it's gotta be short and simple. alexis On Tue, Aug 24, 2010 at 4:27 PM, Danny Briere <[email protected]> wrote: > My information is a bit dated in what I'm going to say, but I used to > know this functionality as XML switching. The players in that space > all got bought up by IBM, Microsoft and others, and it's probably > being incorporated into servers and such. I'm not qualified to answer > whether it goes into this hub standard or not. We would use it > certainly if it were there. Someone else needs to comment on this part > tho.-danny > > On Aug 24, 9:37 am, Robin Boast <[email protected]> wrote: >> Dear Danny, >> >> Thanks for this as I think this clarifies the problem -- in ways that I >> didn't. I agree that the solution (or solutions) has to be at the end point, >> or at least set by the end point. Also that it most certainly is not about >> the "perfect" feed. One person's perfect feed is another person's corrupt >> feed. However, the point I was trying to make, probably badly, is that in >> the world I come from, that of large scientific archives and datasets, end >> users don't have the time or the resources to do too much slicing and >> dicing. As they are usually also subscribing to very fat feeds, they don't >> want to be constantly getting masses of data PuSHed to them that they just >> have to throw away. On top of all this, the data we are looking at PuSHing >> can be used in any number of ways, by any number of users, so embedded tags >> are of minimal use. What "tagging" there is is already embedded anyway and >> will get used where and when it is helpful, but far from universally. >> >> I suppose my problem is that with our feeds the vast majority of our users >> live, and always will live, in the very long tail. This means that embedded >> tags help to a degree, but only to define the most general interest set for >> the users. Maybe that is good enough and is up the them to sort out how to >> get to the more specific interest set, but I continue to think that it is >> not great problem to have some simple user set filtering as part of the hub >> management. So rather than (1) publish to hub, (2) hub strips old data from >> new, (3) hub PuSHes new feed data to subscribers, we get (1) publish to hub, >> (2) hub strips old data from new, (3) hub filters new data for each >> subscriber, (4) hub PuSHes filtered feed data to subscribers. Not >> complicated, but a missing bit perhaps? >> >> Best, >> >> Robin >> >> On 24 August 2010 12:14, Danny Briere <[email protected]> wrote: >> >> >> >> > 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/ >> >> -- >> =================== >> 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/
