3 ms·

Isn't this PubSubHubbub, but not? What differentiates your protocol from PuSH?

tcarnell 16y ago
Thanks for the question! I think that PubSubHubbub is mainly for integration with feeds (RSS, ATOM etc) - correct me if I'm wrong! So the PubSubHubbub is somewhat restricted. So I would say the difference between PubSubHubbub and LiveDirectory is that with LiveDirectory the data that is passed around is JSON, which means that: 1). It can be almost limitless in its structure (using combinations of objects, arrays, string, numbers and booleans) - RSS & Atom have very fixed data structures, so if you want to represent some other data structure, for example a client list, your latest special offers or your company office addresses you're out of luck. 2). JSON data is often far easier to parse and process than XML, so the callback notifications are much more 'developer friendly'.
- ch 16y ago
  Thanks for clarifying your intent, but I think the original commenter is right, there seems to be little here so far that PuSH cannot do. In fact there have been recent proposals for PuSH to gain JSON message formats (I believe superfeedr is now providing JSON data as well). That said, there certainly seems to be room for more PuSH hubs, perhaps that is a direction you can take LiveDirectory. References: PubSubHubBub JSON Draft: http://martin.atkins.me.uk/specs/pubsubhubbub-json http://martin.atkins.me.uk/specs/pubsubhubbub-json SuperFeedr JSON: http://blog.superfeedr.com/json-pubsubhubbub-notification/ http://blog.superfeedr.com/json-pubsubhubbub-notification/
  - tcarnell 16y ago
    Thanks for the extra-reading, I will definately take a look at those. However, I will add that the whole 'pubsubhubbub' thing is very unfriendly (including the silly name) for the people that would be it's most valuable users, ie the people that are generating interesting, novel and valuable online content... ...So in addition to the fact that LiveDirectory is already up and running and working with JSON as the data language, it also aims to make life as easy as possible for BOTH the content publishers AND application developers. Actually, I see think that LiveDirectory is only an intermediate step until website generally get more 'interactive'. What would be cool is to have a standard like: http://somewebsite.com/services.json http://somewebsite.com/services.json (or services.xml) whereby the 'services.json' file would describe what 'actions' and 'data' is available programatically ('search', 'subscribe', 'contact details', 'product catalog' etc). ch, I really appreciate the feedback, this is exactly why I posted this on HN! Please don't think of my response as being in anyway aggressive or defensive :-)
- julien 16y ago
  PubSubhubbub was built to work with Feeds, but works with any type of data (including JSON obviously). Feeds are a great first step, because it's a lingua-frenca! They are ubiquituous from Craisglist to Twitter, thru Flickr to CNN.com... etc Also PubSubHubbub is an open protocol, which means that anyone (including you!) can easily implementing it without locking themselves in a proprietary protocol.

Thanks for the question! I think that PubSubHubbub is mainly for integration with feeds (RSS, ATOM etc) - correct me if I'm wrong! So the PubSubHubbub is somewhat restricted. So I would say the difference between PubSubHubbub and LiveDirectory is that with LiveDirectory the data that is passed around is JSON, which means that: 1). It can be almost limitless in its structure (using combinations of objects, arrays, string, numbers and booleans) - RSS & Atom have very fixed data structures, so if you want to represent some other data structure, for example a client list, your latest special offers or your company office addresses you're out of luck. 2). JSON data is often far easier to parse and process than XML, so the callback notifications are much more 'developer friendly'.

ch 16y ago
Thanks for clarifying your intent, but I think the original commenter is right, there seems to be little here so far that PuSH cannot do. In fact there have been recent proposals for PuSH to gain JSON message formats (I believe superfeedr is now providing JSON data as well). That said, there certainly seems to be room for more PuSH hubs, perhaps that is a direction you can take LiveDirectory. References: PubSubHubBub JSON Draft: http://martin.atkins.me.uk/specs/pubsubhubbub-json http://martin.atkins.me.uk/specs/pubsubhubbub-json SuperFeedr JSON: http://blog.superfeedr.com/json-pubsubhubbub-notification/ http://blog.superfeedr.com/json-pubsubhubbub-notification/
- tcarnell 16y ago
  Thanks for the extra-reading, I will definately take a look at those. However, I will add that the whole 'pubsubhubbub' thing is very unfriendly (including the silly name) for the people that would be it's most valuable users, ie the people that are generating interesting, novel and valuable online content... ...So in addition to the fact that LiveDirectory is already up and running and working with JSON as the data language, it also aims to make life as easy as possible for BOTH the content publishers AND application developers. Actually, I see think that LiveDirectory is only an intermediate step until website generally get more 'interactive'. What would be cool is to have a standard like: http://somewebsite.com/services.json http://somewebsite.com/services.json (or services.xml) whereby the 'services.json' file would describe what 'actions' and 'data' is available programatically ('search', 'subscribe', 'contact details', 'product catalog' etc). ch, I really appreciate the feedback, this is exactly why I posted this on HN! Please don't think of my response as being in anyway aggressive or defensive :-)
julien 16y ago
PubSubhubbub was built to work with Feeds, but works with any type of data (including JSON obviously). Feeds are a great first step, because it's a lingua-frenca! They are ubiquituous from Craisglist to Twitter, thru Flickr to CNN.com... etc Also PubSubHubbub is an open protocol, which means that anyone (including you!) can easily implementing it without locking themselves in a proprietary protocol.