I'm planning to give a talk at tonight's OSJam: http://osjam.appspot.com/ covering the ideas in this presentation (push over xmpp rather than polling) as well as the use of protocol buffers for low latency messaging when you control both endpoints.
@adewale a pet peeve, not to be a downer on XMPP or anything but...
<rant>
ReST != HTTP, HTTP can do streams and therefore does not need to be poll based. Most of what is in the presentation is about specific application semantics that are defined by XMPP. Nothing that similar ReSTfully based (and therefore HTTP) interface can't do and be Web friendly too. It is all in how you define the resources.
On PB consider these too: JSONP, HDF5, ASN.1 DER (et. al), S-Expressions, N3, X3, AOL's SNAC and TLV, and FaceBook's Thrift. And others. Not sure why Google's PB got so much attention since it has been done many times b4...
</rant>
I know ReST can be implemented over protocols other than HTTP but no-one has done it yet.
I don't understand why so many people resisted PB so strongly. It's just a wire protocol that also happens to be an on-disk serialization format. The reason that everybody has built similar tools (e.g. Sun had XDR) is that it's a common problem and no-one has yet built a really good solution which is open sourced, cross-language, simple and isn't coupled to an RPC system (like Thrift).
Before I knew about PB I used to use XStream (gzipped if I needed to save on disk space) whenever I needed an efficient serialization format and PB just gives me a cross-platform binary equivalent.
Wasn't dissing PB, just curious why it has so much mind share given it has been done so many times b4.
ReST..."no-one has done it yet." FWIW you can't really implement it. ReST is an architectural style. It informs/constrains your design space. Try JSR170 and JSR283.
4 comments so far
I'm planning to give a talk at tonight's OSJam: http://osjam.appspot.com/ covering the ideas in this presentation (push over xmpp rather than polling) as well as the use of protocol buffers for low latency messaging when you control both endpoints.
1 year, 3 months ago by adewale
@adewale a pet peeve, not to be a downer on XMPP or anything but...
<rant> ReST != HTTP, HTTP can do streams and therefore does not need to be poll based. Most of what is in the presentation is about specific application semantics that are defined by XMPP. Nothing that similar ReSTfully based (and therefore HTTP) interface can't do and be Web friendly too. It is all in how you define the resources.
On PB consider these too: JSONP, HDF5, ASN.1 DER (et. al), S-Expressions, N3, X3, AOL's SNAC and TLV, and FaceBook's Thrift. And others. Not sure why Google's PB got so much attention since it has been done many times b4... </rant>
stepping down from my soap box now ;)
1 year, 3 months ago by fin
I know ReST can be implemented over protocols other than HTTP but no-one has done it yet.
I don't understand why so many people resisted PB so strongly. It's just a wire protocol that also happens to be an on-disk serialization format. The reason that everybody has built similar tools (e.g. Sun had XDR) is that it's a common problem and no-one has yet built a really good solution which is open sourced, cross-language, simple and isn't coupled to an RPC system (like Thrift).
Before I knew about PB I used to use XStream (gzipped if I needed to save on disk space) whenever I needed an efficient serialization format and PB just gives me a cross-platform binary equivalent.
1 year, 3 months ago by adewale
Wasn't dissing PB, just curious why it has so much mind share given it has been done so many times b4.
ReST..."no-one has done it yet." FWIW you can't really implement it. ReST is an architectural style. It informs/constrains your design space. Try JSR170 and JSR283.
1 year, 3 months ago by fin