Beyond superfeedr awesomeness

superfeedr is one of those great web services that has bridged what interests you on the web with your lazyness to go and check it for yourself. That’s right! More seriously, you don’t have to be lazy to be quickly overwhelmed by the huge quantity of information available to you and superfeedr offers you a fantastic service by delivering information at your door step.

But as it stands, superfeedr is just the tip of the iceberg. It could do much more for you.

Resource sharing

It would be probably be interesting if you could easily share with others (contacts, aggregators, social networks, etc.) links that you find interesting. This means you would become a source of information too. In other words, it’s as if you were generating a feed of links which others could subscribe too through superfeedr. But aside from the form itself, the possibility to automatically (re)publish interesting links is probably useful.

Recommendation support

Considering the sheer amount of feeds parsed by superfeedr and the fact they know the set of feeds you are interested in, it would be quite useful to add a recommendation mechanism in place. It means analysing feeds metadata but also giving weight to feeds based on the number of subscribers they have in the system or how long they retain subscribers. Similarly it would be relevant to publishers to get metrics to monitor how people consume their resources.

A dedicated client

XMPP clients suck. They all do when you want to go beyond pure instant messaging. PubSub is just barely supported and when it is, it’s just not user friendly. Therefore, following what the guys at seesmic have done, if you want your users to enjoy your service, you need a dedicated client. They care naught for your protocol. They want information displayed in the fashion du jour. These days, you gotta look like Twitter. Maybe Process One OneChannel could be a lead.

Integrate with Wave

That one is probably just for the fun of it but Wave is quite fancy-able these days and being able to be notified via a Wave could be a very cool.

Have a mobile presence

Mobiles will be where the market is in the next coming years. New generation mobile phones can support really well HTTP and even XMPP as BuddyMob has shown for quite some time with Android. Being able to broadcast to mobile phones is a must.


Are those overall changes critical to superfeedr? It’s hard to tell. Creeping featurism is never a good idea and finding the right balance between what would make the service richer without making it obscure and without focus is always difficult. In any case, it’s a very handy service that deserves more attention. Happy feeding.

Atom and AtomPub were failed

Joe Gregorio’s AtomPub is a failure note is probably not as provocative as its title may make it sound. Joe knows more than the average lunatic out there about AtomPub considering he was co-editor of RFC 5023 and his work at Google so when he says AtomPub may have failed, one is forced to pay attention.

Joe argues that even though AtomPub hasn’t failed as technology, it hasn’t swept the inter-tubes world away as hoped probably because the rationale for creating such a protocol years back doesn’t really pan out any longer.

I share Joe’s slight disappointment at not seeing AtomPub more spread on the web but I don’t entirely agree with the reasons he puts forward:

So why hasn’t AtomPub stormed the world to become the one true protocol? Well, there are three answers:

  • Browsers
  • Browsers
  • Browsers

The world is a different place then it was when Atom and AtomPub started back in 2002, browsers are much more powerful, Javascript compatibility is increasing among them, there are more libraries to smooth over the differences, and connectivity is on the rise.

I’m kind of puzzled, browsers did exist back in 2002, didn’t they? Sure they are more standardized, Javascript is not a shameful programing language like it used to be back in the DHTML days but nonetheless, browsers haven’t fundamentally changed since then. Moreover, through all the years required to release AtomPub nothing prevented the WG in charge of it to reach out for browser vendors. I don’t remember seeing much of them during the long discussions that took place. I find therefore rather harsh to complain at browsers for the fact AtomPub isn’t spread enough. (Note to the Hybi list, don’t make the same potential mistake).

Joe also suggests that XML was overcome by the couple: HTML+JSON. That is very true and Joe acknowledges that he didn’t think this would happen but when he says:

All of the advances in browsers and connectivity have conspired to keep AtomPub from reaching the widespread adoption that I had envisioned when work started on the protocol, but that doesn’t mean it’s a failure.

Conspired? Come on Joe. XMPP certainly suffers from the priority browser vendors have made in the past years but XMPP isn’t built atop HTTP when AtomPub is. I’m sorry Joe but, if anything, the fact Javascript has now so many fantastic libraries make it even simpler to interface with any protocol based on HTTP. Browsers have everything one needs to build an application conversing through AtomPub.

I disagree with Joe’s reasoning and personally I think there is a much bigger issue here to explain the protocol’s difficulties to be a premium choice for public web services.

Let’s review some social network platforms and the way they expose their data.

Wikipedia

Atom: Only used to view global recent changes and utter failure at actually using the format for what it’s good at. In a nutshell, everything is serialized to HTML and packed into the atom:summary element.

API: MediaWiki offers an API to expose and manipulate data which isn’t based on AtomPub but follows quite obviously the same design considering the document’s nature of a wiki. Note that the API supports several output formats but none of which is Atom.

Facebook

Atom: As far as I can tell, Facebook doesn’t offer any support for Atom.

API: Facebook has its own API which doesn’t really map well to AtomPub even though it’s quite often simple CRUD operations.

Twitter

Atom: Twitter exposes friend’s timeline as Atom feeds and does it well. Their API doesn’t support it however.

API: Twitter’s API is also not based on AtomPub.

Last.fm

Atom: No support for Atom.

API: Last.fm’s API doesn’t use AtomPub, well considering they don’t even use Atom itself, it kind of make sense.

Orkut

Atom: Available but not officially supported as per the documentation.

API: Orkut’s API is based on OpenSocial which if I’m not mistaken isn’t based on AtomPub.

MySpace

Atom: Not from  the public website as far as I could tell.

API: MySpace’s API is based on OpenSocial too, thus not based on AtomPub.

Flickr

Atom: Offers Atom feeds for a wide range of their data from their website.

API: Flickr has its own API not based on AtomPub and doesn’t output to Atom.

Google’s various API

Atom: Extensive support for it.

API: Extensively based on AtomPub even though no public support for the AtomPub service document which kind of limits service discovery.

I’m not trying to point fingers at those services, most of them came to life way before AtomPub became seriously defined (and maybe Tim Bray was right to warn the WG it was taken too long) so it’s not really a surprise it’s not used. In most cases though exposed APIs could be mapped to the protocol as well as the Atom format but obviously that would require major and fundamental architectural refactorings which make little economical sense.

It’s worth noting that some services have hard times even exposing data without degrading their values. Atom is a well-defined protocol that offers a simple view on web semantics. Used well, it offers a fantastic ground for mashup of organized and structured data. This is added value I’m wondering if mentioned social network platforms are willing to propose. In some respects Yahoo Pipes might not have to exist if Atom and AtomPub were properly used. Atom is so much more than pure serialization format. Atom can be serialized to JSON and still be Atom. Atom offers a real path to build powerful and meaningful social graph of distributed data.

Ultimately, data is money and I assume it’s a technical issue as much as an economical one. It’s easy to help building the piping for interoperability but it seems harder to actually open up the tap of data.

That being said, as Joe says:

There is still plenty of uses for AtomPub and it has quietly appeared in many places.

Atom and AtomPub aren’t dead but are probably less visible than one might have hoped, used in more traditional places and I suggest you follow Peter Keane to get a feel for it.

Geolocalization and microblogging

I’ve been working recently with Adrian Hornsby who’s been interested in using the microblogging example I had setup to demonstrate headstock, amplee and some ideas about microblogging in general. Today Adrian asked me how to add some gelocalization information to a message flowing through the system. It took me just a couple of hours to implement it so that now you can push a message like: GEO text [lat,long] through your IM client. This will tell the demo to add a georss:point element to the generate atom entry which will eventually lead to a Google map to be displayed in the web page mapping the atom entry.

amplee 0.6.1

I’ve just released amplee 0.6.1.
This release is a minor release that fixes a few annoying defects and improves overall performances of the internal of amplee:

  • removes many of the usage of the copy.copy function (thanks to Mohanara Gopala Krishnan for his previous help)
  • drops the cmemcache module in favor the python-memcached one
  • adds a prune(member) method to the indexer API
  • extends with a few helpful functions the atompub API
  • adds more unit tests
  • drops the graph subpackage from the egg distribution (and I will remove it altogether for license issue in the next release)

If you’re using 0.6.0 I would advise to upgrade. The API is fully compatible and you’ll experience a more stable product.

I really wish to thank Mohan for his feedback, patience and will to send patches.

I will release a next version to clean out some remaining issue and than I will move toward amplee 0.7 that’ll support Amara 2.0 and will see some internal refactoring.

XMPP, AtomPub and microblogging

Following my previous posts about my work on mixing AtomPub and XMPP together in a single application I’ve worked yesterday on the basic workflow of the application I write.

The first use case is to create a profile using OpenID.

  1. When landing on the application main page the user can enter his (or her) OpenID which will redirect him to his OpenID provider for validation.
  2. Once validated and accepted the user comes back to the application which shows a simple profile page pre-filled with information using the simple registration extension of OpenID.
  3. Upon submitting his profile for registration the application stores the profile following the format described in XEP-0154. It also creates a node in a Jabber PubSub service that will be used as the top-level node of the user. It finally creates a workspace specific to the user within the AtomPub service.

Note the the application I’m writing will conflate two similar notions into one and make them context free:

  1. node in PubSub
  2. collection in AtomPub

Both terms will refer to a channel in the application. So sub-nodes of the user top-level node will be called a channels and each collection within the user workspace will also be called a channel. In other words publishing data to a channel means publishing data to both the PubSub node and the AtomPub collection at the same time no matter the protocol chosen to perform the operation. The channel convention is arbitrary but helpful as it hides the underlying protocol away.

Once a user is registered to the application he can log in using his OpenID. After logging in the user can register, start and stop the internal XMPP client associated with his account. The first step is to register it from the application. Once registered the client can be started and stopped at will.
When the internal XMPP client is registered the user ought to use his favorite Jabber client to register a new account to the Jabber server. Then he should subscribe to the internal client’s contact list that will automatically accept it (probably in a better scenario subscription should be moderated from the user’s profile page).

The second use case is to create channels

  1. The user could create channels using either his Jabber client or using the AtomPub interface.
  2. In both cases the application would create both the according PubSub sub-node to the user’s top-level node and the appropriate AtomPub collection.

The third use case is to publish data to channels with XMPP

  1. The user uses his own Jabber client to send a message to the internal jabber client like this: “publish channel Hello world”. This would translate into “Publish ‘Hello world’ to channel” where channel is the name of the channel to publish to.
  2. The jabber server would forward this message to the internal client who upon parsing it would understand it must publish the sent data to the according PubSub node. First it would enclose the data into the atom:content of an atom entry and publish that entry as the node’s item.
  3. When the item is published the Jabber server would send a notification back to the internal client which could then create and store the according AtomPub member entry to the appropriate collection. The entry would become visible via the Atom feed of the collection.

Note that waiting for the notification to be propagated back to store the atom entry within the collection rather than doing it immediately when publishing to the PubSub node is not gratuitous. Indeed the user could publish items directly from an external client that understands PubSub. By doing it the way described above we ensure that even in such a case the internal client will be informed a new item was published to a node it is subscribed to and therefore the application will keep in sync’ no matter what.
The fourth use case is to publish data to channels with AtomPub
This would be similar to the previous use case except the entry point would be the AtomPub interface and that of course a message would be sent through XMPP accordingly.
Deleting items from channels would work in the same fashion.
Of course the user’s channels would then be publicly available and other users could subscribe to the Atom feed, to the internal XMPP client or to the user’s PubSub nodes.

From there on the application could be extended so that for instance users can comment to each other and ensure that the channels’ items contain that information, for instance using RFC 4685 within each item.

These are few things I’ve been working on. The application is not ready yet and it might take a few days for it to complete and hopefully some of you will be interested in testing it then.
Regarding the platform used, Python and the following products:

  1. headstock through Kamaelia for the XMPP layer
  2. amplee for the AtomPub interface
  3. CherryPy 3.1 for the HTTP serving
  4. amara for the XML handling