Having read the about Butler, and taking into account the considerable thought and concepts already expounded, I'd like to suggest an aspect to the conversation that may prove more relevant over the next 18 months. The consumption of Drupal sites by mobile devices is actively being addressed, but there is also an increase in the number of mobile applications that are accessing the content of Drupal sites directly through services, and allowing mobile users to interact with that content within that application. An excellent example of this was just presented @ DrupalCon in Chicago.
In addressing mobile application usage of services from a Drupal site, the different use-cases of mobile devices themselves alter the paradigm of the "always-on" connection required to use the content of a site. Because people who use mobile devices invariably take them places where there is no connection, an application will need to address the issue of storing, syncing, queuing, aging, and proving the general logic to govern data traffic-directing. While this obviously can be handled within the implementation of services, I will posit that the architect of this system (Drupal site, mobile application[s], mobile use[rs]) may want to actively govern the decisions that have to do with the traffic-directing, not to mention the interaction with content.
That said, I'd encourage all of us involved to consider what level of abstraction/constraints/rules/logic that you want to be addressable within the head-space of this initiative governing services to mobile applications and their users. I don't have any definite recommendations at this time, but want to shine some light on what I see as a surging user-base by the time that D8 comes to fruition, and enjoin a conversation.
Comments
Interesting
As I was just recently working on the data synchronization and offline storage question for the DrupalCon Chicago mobile app, which drew about 95% of its data from the DrupalCon web site, this question is near and dear to me. :-) I'm not entirely sure what it is you're suggesting, though.
In the current plan, if a client (mobile app, remote server, doesn't matter) requests node 5 using, say, $_GET['q'] = 'node/5' and an HTTP Accept header of "JSON" (rather than text/html), then the router layer would take that information and rather than returning a formatted page return a JSON serialized copy of node 5 (possibly with some partial formatting to HTML, as is being discussed in the issue queue) and bypass the HTML page logic flow entirely. The client can then do whatever it wants with it.
If you're talking about defining from Drupal how long the client should wait before checking for updates, well, that would cover some use cases but not all. My knee-jerk response, though, is that HTTP already has cache control headers. We should use them. Using them effectively may mean going as far as a response object (to complement the "butler" request/context object), on which we can set headers such as cache control. It's up to the client, then, to decide how best to honor them.
Or do you mean something else?
I would actually encourage people to read the writeup linked above about the DCC Mobile app. There were a number of interesting data syndication problems that we had to work around, and a more standardized way of handling them would be useful. Possibly out of scope for WSCCI, but useful nonetheless.