On Jul 17, 2009, at 9:31 AM, Adrian Bateman wrote:
On Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote:
On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote:
I agree with Jonas and I'd like to understand the expected use cases
better too. I think I get the point that making the network access
seamless regardless of whether there is network connectivity or not
simplifies the network request code but seems to me to require more
complex interception code.
There is a tradeoff when adding the complexity of unreliable networks
- either more complex client application code, or more complex client
interception code.
In our experience, we have found the latter to be actually more
manageable for cases where the interception and off-line serving is
done in a relatively application-independent manner.
This isn't a pattern that I can readily map to customer requests
we've received nor is it a familiar pattern to me personally.
DataCache's interception pattern has existed for a while. A good
survey of mobile data management and transaction support has covered
this pattern [1]. The discussion there is not limited to Web
browsers,
though.
I scanned through the paper you cite but it isn't clear to me which
part of that is equivalent to your proposal. Is it possible to point
out which section I should read more closely?
The paper talks about flexible client-server architecture in section
2.1:
[[
The roles of clients and servers as well as the application
functionalities can be dynamically relocated. The distinction between
clients and servers may be temporarily blurred for performance and
availability purposes.
]]
Further, the paper identifies one of the mobile file systems as Coda
in Section 3.4 [1]. If you were to read the Coda paper, you would see
the following text in its section 3.2. By the way, Coda was first
conceived in early 1987 at CMU by Prof. M. Satyanarayanan's group.
[[
Individual replicas are not normally visible to users or application
programs. All they see is an ordinary file system mounted at /coda.
This illusion is created by the Venus cache manager on the client.
Venus intercepts all file references to /coda, discovers which servers
hold replicas of a volume and fetches file and directory data as
necessary from those servers, and manages cache copies of this data
using files in the local file system as containers.
]]
The pattern that isn't familiar to me is one where it appears that
application logic is provided by interception. Given the generic
nature of the Mobile Transactions paper you focus on application
independence, are you proposing that the DataCache is part of a
solution with no application specific code?
Interception provides for the ability to introduce application-
specific code that in emulating the server during disconnection.
In other words is there some "platform" component, whether that be
a JavaScript library or otherwise server-provided infrastructure,
that operates generally at the interception point.
An application can choose to use a library via which application-
specific code is tied to the interception, but this is not necessary.
Alternatively, is it application specific code that will be hand
written for my use case every time?
Generally speaking, yes. However a certain class of applications may
choose to use a protocol such as Atom which generalizes the server
behavior in terms of a specific set of semantics. In such a case, it
may be possible to share a single library across applications that may
do the interception.
When Jonas asks the question about how do you expect people to use
this, what comes to mind for me is a question about a scenario. "I'm
a web developer and I've built an application that makes XHR calls
to exchange data with my server. I'd like to provide access to this
application in situations where I am occasionally disconnected
because of intermittent network connectivity.
This is precisely where the application programmer needs to make a
call - do I want to offer this functionality to a user when they are
unable to access the network. If not, then skip the rest and return
with just an error message.
Do I now sit down and try to figure out what network requests I need
to intercept and write JavaScript code for handling all of those
requests?
For those application behaviors, that require HTTP requests, that are
to be supported off-line, I need to figure out what the off-line
response should be. Then I have to translate this in to JavaScript
code and attach it to interceptors. Certain application developers
will be smart about out how to move code from the server environment
to a client environment. Some developers will figure out an automated
process for doing so, whereas others will be able to do so with manual
support and computer guidance. In some cases, neither may be possible.
Or is there a library I can just plug in that, with some
configuration, does that for me?
For example, Oracle's and prior to that Siebel's technology could
situate application behavior to run on either client-side or server-
side. The same behavior could be executed on either tier without a
programmer having to write it twice or differently for the two
situations. However, this is not in the context of HTTP or JavaScript.
However, I expect that application developers who care so much about
mobility would be able to come up with such libraries that could offer
code portability and client-side server emulation without requiring
separate programming for both sides.
Or is this something my server infrastructure should already support
and if it does I just turn it on but otherwise I'm out of luck?"
I don't want to say that someone is out of luck. There is some
knowledge of what the server will do with requests. So long as you can
emulate that behavior in JavaScript, you are in the game. It is only a
question of how much effort may be involved in producing the required
JavaScript.
Does the situation change if I am building an application from
scratch that wants to deal with network disconnections?
In that case, you should be able to take advantage of the presence of
interceptors and write your code to move to the client when client-
side execution is desirable. If this application is used in
environments that do not support interception, then it will work just
fine with server-side execution. Of course, the application won't do
the right recovery when it is disconnected if interception is not
supported.
On the other hand, it appears to me that it proposes an entirely new
programming model - did you consider an incremental approach that
modifies window.applicationCache? Did you have particular reasons
for rejecting that?
Yes. I certainly considered window.applicationCache. I have
previously
proposed including additional things in HTML5, but the feedback was
that the application cache could not be broken down in to any further
primitives due to bootstrapping requirements [3].
I certainly feel that applicationCache can be composed with the
primitives of DataCache + versioning. On the other hand, the converse
is not possible due to ApplicationCache's:
a. strictly static manifest serving,
b. lack of support for version-free resources, and
c. missing authorization checks.
[1] http://portal.acm.org/citation.cfm?id=992378
[2] http://o-micron.blogspot.com/2009/04/how-is-bitsy-different-from-
html-dojo.html
[3] http://lists.w3.org/Archives/Public/public-html/2008Nov/0224.html
I understand that your DataCache proposal provides different
functionality to AppCache. I wasn't suggesting that they were
equivalent.
I am glad to see that you see a different set of functions offered in
DataCache. Several commenters before you have taken the exact opposite
position.
However, the AppCache as specified is getting implemented today (it
is in Safari and Firefox with other implementations on the way). The
problem I have is that I can't go implement AppCache and then add on
some new methods and alternative interception-path to get DataCache-
like features - I have to write a completely independent mechanism.
If I propose that we build AppCache and then DataCache, someone will
say, "Hang on, didn't we just build this - why do we need two?"
OK. I get that. I also consider this to be an important challenge for
everyone concerned. I thought I would write a concrete proposal.
Oracle could help out with building a reference implementation for
multiple browsers and make its source code available. What else can I
do to help?
While it might not be the perfect solution (we know the web far from
ideal and is a lot of compromise), this type of proposal would be a
lot more compelling to me if I could say "This is what we have to
add, this is how, and here are the use cases that make it valuable"
with a roadmap for extending what people are already building
instead of something brand new.
Would you mind explaining the last point "with a roadmap for extending
what people are already building instead of something brand new." for
me? I would definitely strive to make the proposal more compelling.
Cheers,
Adrian.
[1] http://portal.acm.org/citation.cfm?doid=507052.507053
