The increasingly popular FriendFeed is proposing a new protocol known as Simple Update Protocol (SUP). The problem FriendFeed is encountering is noting new. They monitor a RSS feeds over a variety of services for each user. This can really add up. To keep things timely they poll them frequently. Generally speaking this is a very wasteful process since the majority of those feeds likely didn’t change. That’s wasted resources. SUP in a nutshell is a changelog for feeds so that a service like FriendFeed can check only the ones that changed. This allows for quicker updates with less polling. Here’s my analysis of the proposal.
Tag: xml
Google today released Protocol Buffers. Protocol Buffers is their “language-neutral, platform-neutral, extensible mechanism for serializing structured data”. In general it’s pretty interesting stuff, and looking over the docs, seems pretty well thought out.
I agree XML is bulky and wasteful for the task. There’s a reason why many web developers prefer JSON rather than actual XML when using xmlHttpRequest: XML parsing can be a real performance killer. JSON in my mind is currently the winner in this department since it’s light weight, simple, and a can be interpreted by pretty much any language on the planet (may need to install a module, gem, extension, or include a class). The downside to JSON is that it doesn’t really allow you to define structure. JSON also is still not binary format, so you have a performance penalty to parse the string. The upside is that JSON is rather easy for humans to read (great for debugging). The NY Times even made a database abstraction layer called DBSlayer that interfaces using JSON.
Serialized PHP has become somewhat popular (Yahoo Developer Network API’s support it), but it’s language specific, though interpreters that can read/write it exist for other languages including Perl, Python and Java. It’s also somewhat complicated for what it provides. At a glance it’s a string of garbage until you break it down.
It looks like Google already has support for Java, Python, and C++. It’s only a matter of time before Perl, PHP, and Ruby get support for Protocol Buffers as well.
I could see Protocol Buffers being pretty useful in combination with Memcached.
It’s great to see Google open sourcing stuff like this.
John Resig has an interesting blog post on embedded JavaScript. It’s something I’ve been thinking about for a little while.
It would be awesome to see a PHP extension to embed SpiderMonkey into PHP. As far as I’m aware Facebook is the only one that’s taken a step in that direction with FBJS, which uses Mozilla source code. Perhaps that could be a starting point.
Considering the ubiquity of JavaScript, using SpiderMonkey, which is already available for Perl and Python, or Rhino (for Java) would make sense. It would allow for JavaScript to be for logic what XML is for data. In my mind that is nirvana for the web.
XML made our data portable. JavaScript can make our logic portable. Seems practical enough right?
For those who question security, it’s really up to the client to decide if it should parse JS, and what subset it should allow (perhaps no eval()). Having an API based on JS is really no less secure than any other language including one that’s home made. It’s advantage is that it’s used everywhere else and makes your API easier to work with.
This could be cornerstone of Web 3.0. Web 2.0 was largely about shared data and isolated small services. Web 3.0 could be about shared data and shared services.