Seamless online-offline applications

Use cases:

The use cases described below are based on applications accessing  
their data through Web feeds and their linked resources in conjunction  
with the semantics of GET, PUT, POST, and DELETE defined in the  
AtomPub protocol. The feeds considered here are in the Atom format.  
However, there is a good likelihood of a similar interpretation for  
JSON feeds. All the use cases below are in the form of browser  
applications.

1. A sales rep is browsing their list of opportunities from a CRM  
system when traveling to a medical center. Once they arrive in the  
medical center, they turn off the radio capabilities of the device  
such as cellular packet connection and Wi-Fi. The application  
continues to function and provide access, albeit limited, to the  
application function such as adding notes to the opportunity,  
reviewing opportunity details, identifying and adding products to the  
opportunity. OTOH, the user may not be able to conduct searches for  
potential team members while she are offline.

2. An email user is browsing their collaboration space in the form of  
email, appointments, address book, and to do list. His train passes  
through a tunnel and he loses the ability to update and create tasks,  
appointments, and email messages.

3. A health care professional works in a remote hospice with no  
network connectivity. They are required to maintain a secure record of  
all the services provided to the infirm. Periodically, the  
professional leaves the facility and arrives back in a networked area  
and the care records are conveyed securely to a processing center.

Rationale for a solution:

In the above use cases, applications need the ability to perform  
standard AtomPub operations even when they are disconnected. The  
semantics of AtomPub define the result of performing PUT, POST,  
DELETE, and GET in a way that deferred submission of client requests  
is possible and, in some cases, and sufficient for high  
responsiveness, as it may not even involve any server logic. In the  
case of other requests, clients can perform certain logic which will  
be repeated on the server.

Conflicts may arise regardless of whether disconnected updates are  
allowed since there is no pessimistic concurrency on the Web. So,  
applications can deal with conflicts arising from disconnected updates  
much the same way.

Atom feeds are a mature format, and AtomPub has been in use for over a  
year. It layers nicely over existing Internet infrastructure and does  
not pose any significant new security threats. A number of highly used  
APIs are now employing a combination of the two for developing browser  
applications. Disconnected operation over AtomPub keeps the  
transaction model of the Web, i.e., a new transaction for each  
request, intact. It also makes programming for disconnected use,  
including conflict management, server logic replication, and  
synchronization a lot easier for applications.

Solution:

The solution involves:

1. Intercepting all HTTP requests made by applications to a browser  
for a known set of URLs including those made from form posts, XHR, and  
links
	* Temporarily process unsafe requests and provide tentative responses  
using standard AtomPub and replicated server logic when server is not  
reachable.
	* Process safe requests and generate responses using results of prior  
unsafe requests.
2. Pre-fetch and hoard representations of resources required by  
applications based on a known set of feed URLs and semantics of  
interrelations among them.
3. Submit unsafe requests to server when server is reachable and  
reconcile with locally stored representations of the same resource.
4. Alert any interested event target about synchronization errors and  
other state changes.
5. Guard application data against malicious or malevolent usage and  
limit access to authorized applications

The gaps with current HTML5 implementation are:

1. There is no mechanism for (1) above
2. (2) and (3) cannot be performed for a domain unless a browsing  
context in that domain explicitly initiates the process and is active  
while this is being performed
3. Existing client-side storage does not guard against cross-directory  
or even cross-user attacks.
4. Existing client-side storage cannot guarantee any correspondence  
between local transactions and network requests. As a result, update  
operations that may succeed locally may fail for a variety of causes  
during synchronization leaving the application user puzzled.
5. Existing client-side storage requires serialized access to data,  
which may be far stricter than what an application or a server would  
provide.
6. Server-sent events and Web socket formats and protocols are  
immature as compared to AtomPub, just based on their standardization  
status and amount of current usage experience.

Having said this, the solution being proposed has been implemented  
using JavaScript, as a Firefox extension, and as a plugin to desktop  
and mobile browsers. It is found to support a very simple and  
effective programming model, works nicely with existing servers and  
applications, and can be accommodated without significant client  
overhead.

I hope this serves as a decent starting point for the discussion on  
seamless online-offline applications which can use the network to the  
maximum extent possible, while still providing responsiveness and  
availability of local applications, and ensure authorization that is  
no different from the server's behavior without storing user  
credentials.

A proposal for the solution above in the form of programming interface  
for controlling synchronization and interacting with AtomPub servers  
inside a client-side store is available [1]. Oracle invites comments  
on this draft and requests the working group to consider its inclusion  
in the WG's deliverables. More documents explaining the motivation for  
this approach as well as comparisons with other techniques such as  
Gears and FeedSync are also available [2]

Regards,
Nikunj Mehta, Ph. D.
Consulting Member of Technical Staff
Oracle

[1] http://oracle.com/technology/tech/feeds/spec/bitsy.xhtml
[2] http://oracle.com/technology/tech/feeds

P. S. If you are having trouble viewing the draft, blame your  
browser's content-type sniffing algorithm (and the inability of my  
server to set the correct Content-Type header). Please save the draft  
spec page locally and use it with your favorite XHTML browser.

Received on Wednesday, 15 October 2008 14:11:44 UTC