Posted by & filed under Tech.

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.

  • Matt Terenzio

    That makes sense but then I just think it should be an attribute of the fatPing element. Description just happens to be present because it’s an RSS payload, and even in RSS it’s not required.

  • cshotton

    Enclosures are problematic as they require an extra transaction with the server, which defeats the whole point of a fat ping.

    I’m not sure what the proper syntax should be or what the right mechanism is to accomplish it. But MIME types for payloads are a well-understood and necessary part of almost every transport out there. It’d be good to see rssCloud expand beyond the limitations of text-only payloads, IMO.

    If you can suggest a better mechanism, I’m happy to jump onboard! I just want to be able to use all the rssCloud code I already have written to do some stuff besides news aggregation.

  • Matt Terenzio

    I think the title and description are merely what was in the rss item that is being forwarded.
    The payload could be anything so you are free to add what you want.
    Meaning there could be an enclosure inside there as well, which clients already understand.
    I have a bad cold. Apologies if I’m missing something or being stupid.