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
