Reading Lists with state

Although easy to store on the web , and easy to use to  share your feed list,  OPML Reading Lists need new features including server-side, stored, state information and access to a networked valueHolder object type version of readingList state. A reading list user would then be able to seamlessly use any instance of any feedReading client to pick up the feeds encapsulated by specific list exactly where that specific user last left the list.  Lets say that there are 50 new feed items belonging to 10 of my ReadingList’s URLs in the morning. On my laptop at home, i manage to read 10 . Then, in my car on the way to work, via a Reader equipped satellite radio, i listen to 5 more podcaste items before arriving at work where i scan the remaining 35 feed items. This scenario involves 3 clients and 3 separate feedReaders that in today’s world are each capable of subscribing to and downloading all 50 feeds in triplicate. Today, there is no way for these readers to share state, to share the data that progressively updates as i wade through the 50 feeds. What i want is a seamless handoff off an updated awareness of both read and  unread items as my presence shifts among the devices on the way to work. The rest of the post is a discussion what and how for one possible solution that extends reading lists and that adds an app server that can update and hold values of these networked list objects.

If you use reading lists and just 1 client to check for feeds there is no need for new features. That single client would be the only location needed for storage of important meta information regarding the feeds and the delivery of items on those feeds. For any given feed or url in the list, the client knows when it needs to poll,  requesting a pull of new feeds from that url.  As long as you always use the same client the reading list entries are handled correctly regarding last visited  state and with respect to dupes because a single client knows how to avoid duplicate feeds on the url. It can diff the meta data just received against data from older items. Now introduce a 2nd feedReader client by sharing the reading lists on your PC with the reader installed on your phone and see what happens. Everything gets pulled twice. Without access to the same internal state information  used by the first client, the phone has no visibility into what time each url in the list was last requested and no access to meta data like the most recent pubDate on items just pulled by the other client. Nor does it have any information on duplicates. On the phone, you can get your feeds but it will be just as if you are using an email account where you save all mail items on the server while using multiple mail clients. Each client downloads the entire list of mail in the inbox even thou you may have already read the mail.

A shared folder of MyFeeds as I last accessed them , stored server-side where it associates users (myself) and lists (mylist) with a 1 : 1 cardinality is one solultion to the problem. The virtual folder encapsulates client state information like the last time that i read a particular <title> belonging to a feed URL, storing server-side attributes like "last_access_date" on the feed and "has_been_read" on each title in the feed. Any feedReading client on any device has access to the folder and to accurate context covering details on what i last read and when.  All that i have to do to use the reading list in a consistent fashion is get access to the web on a device with a reader capable of accessing this shared folder.

Assume that you have  http://code.google.com/apis/gdata/protocol.html providing "shared folder" features. Look at the Gdata link for "Inserting-a-new-entry". Its focused on the provider and not the consumers of feeds, but it is so close to being a compelling example that some speculation around the fringe of the supported functionality is merited. This is scalable and it supports a full Rest   interface. In the details of the "201 Created" section you can see the xml code excerpt below:

<id>1 </id>

<link rel="edit" xhref="http://example.com/myFeed/1/1/"/>

<updated>2006-01-23T16:26:03-08:00 </updated> 

The link and the id above are pretty close to what you would need to have a uuid on the association between the user (myself) and the <entry.title> where you want to store the attribute "read or unread". Once someone convinces google to extend this initial offering for rss in the GData api, support for the reading list with shared state is done. Any feedReader on any device marks a title to "has-been-read", generating a local event that delegates to a proxy to GData where a POST/UPDATE occurs on the URI and data entry representing the distributed object encapsulating the state of my interaction with the collection of titles that belong to a specific feed. I could switch devices and do a GET to access the shared folder in the state where i left off while i previously was accessing my reading list. 

The Box in the living Room versus Rss everywhere

Who benefits from the requirement for a set-top box in the living room that does double duty as a receiver gateway for any incoming digital media (netFlix via the web) and as a distribution hub for syncing media to other local devices (forward myRingTones to my cellphone, forward my podcast to the XM device)? With this type of network organization both network endpoints involved in media transfer are fixed so that transmission across the net of copyrighted material covers a safe, consistent, and defensible route. This is a boon to content owners with piracy concerns. Utilizing a hardware node that is always the transmission destination within the home, content owners exert maximum control over the implementation of DRM and over the codec processing required to render transmission data into playable media. Each network connection made for the purpose of updating my household media library, is made with the assurance that my account has been authenticated, that my subscription has been paid, and that i will have difficulty ripping and re-burning the media that is being received. Piracy risks that preoccupy content owners may be minimized – but it is not a strategy that comes close to providing optimal consumer choice.

The new linksys product is part of a partnership with Yahoo designed to ease the task of syncing media that has been downloaded with TV , Stereo and other gaming components located in the living room or brought there for the express purpose of local file sharing. Recent reports posit Google cube as a similar product. Microsoft’s media center PC product also sits in the living room although it handles many other functions besides DRM. New devices like the slingBox virtualize my content, allowing me to watch any show on my list even if i’m in a hotel across the country from my living room. Sony’s location free offers features similar to slingBox, funneling content first to the hardware device where its available to be forwarded to other devices. Every one of these hardware devices intended for the living room utilizes hardware encryption, hardware DRM for a consistent and predictable distribution of media files or streaming media from content providers to legitimate media subscribers.

The holy grail for personalized e-media – play what i want now, wherever i am, on the device in my hand – is getting a lot closer to reality. TV shows can download direct to itunes for playback. GoogleVideo distributes mpegs and avi type files. Companies like brightcove supply enabling infrastructure so that any content can be routed to any subscriber device. Fireant delivers your media to any of your devices. RSS allows you to virtualize the storage of your global "playlist" and to access your personal channels list from any device affording web access. "Search, Browse, Subscribe" techniques are used to subscribe to (update) content, adding the content to channels in a virtual playlist. Playlists are the "what", RSS is the glue for connectivity and transmission – the standard that any net-connected device can understand as it uses the playlist in order to retrieve and to play your content whenever you want it. Playlists simply exist on the net – its totally unnecessary for either the list or the retrieved media to be tethered to any hardware in any fixed location like your living room. Any device at any time can retrieve the list, using links there in order to access the actual e-media content. With a virtualized menu of "my personal channels" and with mobile devices all coming equipped with an Rss Reader, wherever you have a net connection your virtual list becomes the available channel directory on the device. You play whatever you like wherever you are without ever having to consider how to sync up a handheld device with the hardware hub in your living room.

An example using virtual channel e-media without being tethered to any hardware hub in the living room involves a commuter with a playlist including a traffic feed. The virtual playlist includes the url for the traffic feed. Via the playlist, the streaming audio for the traffic can be played on a web-radio before departing from the home for work. In the car, XM Playlists incorporating the same technical glue are being used to organize satellite radio content. Eventually, tuning practices for these radios may include the capability to "tune to" URL’s. Sony is now equipping its new devices with features that leverage RSS – using psp rss reader the PSP can access the same traffic reports. At work, the same virtual playlist can be used to connect to the traffic before going home. None of these media scenarios need to be funneled through a device in the living room. The only real requirement for anytime, anywhere access to the media is a net connection and access to the playlist that includes the traffic report.

In terms of the details of encryption and DRM, the "hardware in living room" solution contrasts with an alternative software implementation of DRM in ways too numerous and too complex to wade into. For the ambitious needing more, see pg 11 – 14 of this Cato Institute publication . For any mobile device with an open software applications stack – like a phone or a psp – encryption and DRM processing meeting just about any level of requisite security is a straightforward matter. Binary media in transit to the device can easily be protected. However, hollywood and and the RIAA believe that any networked, web connected node where subscriber authentication and DRM license mediation occurs, and where media transcoding occurs is also an occasion for piracy- this belief and distrust is behind the support of hardware DRM in the living room because hollywood controls it. Although technical practices provide "always-on" access by my phone, my psp, or my XM device to the latest and greatest version of my playlist or the playlists of any of my friends, giving me the ability to play any of that content anytime, anywhere, content owners prefer hardware implementations of piracy prevention schemes that restrict any conceivable opportunity for diversion of media outside the sandbox.

These new hardware products, intended only for the living room assume that delivery of all media is made to the living room first – they do a good job protecting the interests of content owners and anti-piracy advocates, but at a price to anyone with a preference for playing anything, anywhere, anytime. When i have to bring my phone into the house first in order to sync a new ringtone, or when i have to bring my psp into the living room first in order to pick up a new movie trailer because the psp does not have the requisite DRM features that only exist on the piece of hardware in the download device located at home, my options for playing anything, anytime, anywhere are all impacted. The hardware devices for the living room include lots of convenience and easy-to-use features. As evidenced by the maneuvering over the analog hole bill , the content industry, while not always up-front in declaring their real intent, is more into piracy control than consumer choice.

 

 

technorati tags: soho, podcast, rss, set top box, e-distribution, home video, youtube, video