The fat ping addition to the rssCloud infrastructure is a great new feature. After pondering all the myriad of application opportunities it opens up, it occurs to me that there would be value in expanding beyond the implicit content types supported in RSS. As it stands now, the current CloudPipe examples pass through the same RSS content fields present in the originating feed. That means clients will only expect to see plain text or text with embedded (x)HTML mark-up tags and entities.
The ability to embed rich media types directly in the fat ping message would open up a lot of new application types. Image feeds, pushed audio (think instant voice mail), and other sorts of mixed media (multipart MIME, HTML with accompanying media, for example) would all be possible if clients knew how to interpret the type of media before trying to render it. Adopting an optional attribute that specified a MIME type and possible encoding format for content-containing entities would be a HUGE addition to this extension without requiring much, if any, additional work by client authors.
An example might look like:
<description type="image/jpeg" encoding="base64">...base64 encoded jpeg spew here...</description>
The PubSubHubBub spec supports embedding non-text content types in fat pings as a side effect of the Atom spec’s “type” attribute on content entities. However, they don’t explicitly support specifying an encoding scheme.
As with Atom, RSS assumes specific types (e.g., text with embedded mark-up) in the absence of any specifier. So the addition of a “type” attribute is purely optional and would provide clients looking for it with rendering hints as well as an ability to avoid trying to display content types they don’t understand. The up-side is that we get the ability to push all sorts of media and not just text. I think this would be an awesome addition going forward and it should be completely backward compatible with any RSS clients that parse properly formed XML.
Adding both content type and encoding format makes the payload of a fat ping essentially identical to the body of a HTTP response in terms of information available to the client. And every modern OS out there has all the tools needed to interpret and render that sort of message. It also provides a small, but critical addition not present in the Atom/PSHB stack with respect to encoding schemes.
So, my modest proposal is to add optional “type” and “encoding” attributes to the <title> and <description> entities as described above.