John Reynolds's Blog

Disconnected Browser-Centric Clients

There is a huge paradigm gap between writing a desktop application with something like Swing, and writing a browser-based application with something like Java Server Faces. Frameworks like NextApp's Echo2 go a long way towards narrowing the gap, but there are still underlying disconnects that just won't go away...

Just from the practical standpoint of learning how to program, this is a big deal.

I know that some folks wish that browser-based applications would disappear... but I think that adopting that credo would be a mistake. The "old school" desktop applications aren't truly suited to a mobile lifestyle where an individual may connect to the Web from a variety of devices. In a single day I might use my home computer, PDA, mobile phone, work computer, and public kiosk to access my applications and data.

That said, I must admit that most of the current crop of browser-based applications don't quite cut the mustard: If you can't connect to the Web, then you can't use your applications.

We need a blend... We need applications that can be accessed from any device connected to the Web, but with persistent components that reside on the devices that we actually own.

I'll use Google's Calendar to illustrate what I have in mind: I love having a calendar that I can access from any web connection (actually, it doesn't work from my PDA yet, but hopefully they are working on that). I also love the ability to share my calendar with others (particularly with my wife).

What I don't love is losing access to my appointments when I am not online.

I want a persistent component of my calendar on all of the devices that I own. I want my devices to "synchronize with the mother ship" when connected to the Web, updating themselves from a central data store, and passing along any appointments that I might have recorded while offline.

Fortunately, Google has thoughtfully provided a Web Service Interface to their Calendar, so it is quite possible to create a client application to satisfy my wants and needs... I can have a desktop application in addition to my browser-based application if I so choose.

The down side to dual applications is that there's something clunky about this approach...
Accessing a desktop application when not online, and a browser-based application when I am online seems rather like a kludge.

Call me crazy, but what I'd like would be to always start from my browser, type in or select a URL, and have the appropriate version of the application run... If I am online, give me access to the full blown web application. If I am offline, give me access to the persistent components on my local machine. Adam Bosworth has written extensively on the subject of disconnected web applications... but his solutions always seem to end up relying on making changes to the browsers themselves, and I just don't think that's likely given the vested interests of browser manufacturers.

Roshan Shrestha's article "Take Your Tomcat On The Road" gave me an idea for supporting disconnected web applications that does not require the support of browser manufacturers: Create a locally hosted web application to do your bidding.

In my Calendar example, write a locally hosted web application that interacts with the Google Calendar web service. To access this application, simply enter the proper URL in the browser. If the device is offline, the local web application displays the "disconnected client" interface... If the device is online, the local web application redirects the user to the "online client" interface provided by Google.

I might be the only person on the planet who finds this approach attractive... but then again maybe there are a lot of other odd people out there who want something similar.

The biggest obstacle that I see to this approach is the installation of the "disconnected client" on the local machine. Roshan has demonstrated that it's a breeze to bundle a fully functional web application in a neat little package... but how to get that package onto a user's devices?

Would it be possible to use Java Web Start to install something like Roshan's "Tomcat On The Road" package on a user's machine? I'm really not sure... but hopefully somebody out there can help me find out.

Comments

• Couldn't agree with you more - it would be great to have web app's that also kept a local copy for when you are offline.

  Posted by: hlovatt on August 03, 2006 at 03:58 PM

• It already exists, and it's super cool. It's called WebStart.

  Posted by: cajo on August 04, 2006 at 06:15 AM

• Cajo,Are you saying that WebStart can be used to install an application bundled with Tomcat? Can WebStart be used to add a new application to an already installed copy of Tomcat?Either way, I'd love pointers to examples.While I don't really mind the overhead of multiple Tomcat copies (one per "disconnected" client)... it would definitely be better if all my locally hosted web clients shared the same app server.-JohnR

  Posted by: johnreynolds on August 04, 2006 at 06:26 AM

• Why do you even need tomcat?WebStart can allow a Java desktop application to be loaded into your machine over the network. The application has the option to run when you are online only, or to also allow offline operation. It can even resync with the server, to see if there have been any updates to its codebase.Aside from its atrociously poor security model; it pretty much has everything you seem to be looking for.As for pointers, I highly recommend starting at the beginning.JohnC

  Posted by: cajo on August 04, 2006 at 06:52 AM

• JohnC,Please re-read my blog a bit more carefully... I want to launch this application via my browser, and have it display in my browser. I want to use borwser-based presentation techniques for my user-interface layers.I know those are odd and arbitrary requirements... but please humor me, I'm odd and arbitrary ;-)Setting aside my requirement that the application display in the browser... it is possible to launch a local Java desktop application from the major browsers?Thanks,-JohnR

  Posted by: johnreynolds on August 04, 2006 at 07:10 AM

• Gotta get this square peg in the round hole..... ;-)

  You are better off writing rich client apps that work with REST/JSON/Whatever to interact with your server whenever possible, and then fall back on the less rich yet ubiquitous web application when necessary (kiosk).

  Richard

  Posted by: rbair on August 04, 2006 at 07:56 AM

• Humor me Richard,For the purpose of this exercise, let's say that I don't want to use two different pardigms for writing the user-interface layers... I've got to have the browser-based UI skills to write the version of the application that I access from the kiosk... so why not use these same skills to write the disconnected client?Treat this as a thought exercise... If you had to get a browser-based application installed on a remote user's machine, how would you do it?Thanks,-JohnR

  Posted by: johnreynolds on August 04, 2006 at 08:04 AM

• > it is possible to launch a local Java desktop application from the major browsers?Yes. That is the cool thing about WebStart.I suppose if you really like that 'browser' look; I'd bet by now some person, albeit one with a bizarre sense of humour, has written a crippled L&F for Swing that looks like AJaX. ;-)JohnC

  Posted by: cajo on August 04, 2006 at 08:05 AM

• Wow JohnC!You really should be in marketing with great ideas like that ;-)-JohnR

  Posted by: johnreynolds on August 04, 2006 at 08:21 AM

• The trick about this idea is avoiding the black-hole syndrome. A server-based application with a web interface plops the Internet into a carefully selected point in the control structure. Much of the value, and not a few of the flaws, of web applications come from this division. When you start moving value out to the desktop, for disconnected use, where's the new dividing line? Are you going to move the whole data center, a million-user grade DBMS, clusters and security and all that? Of course not, you'll have a single app server and a single-user DBMS and no clustering to speak of and let the desktop context provide your security. But how much do you move, and how do you relayer the application (or do it right the first time) to minimize redundant-yet-different implementation around these differences?

  I'm also a bit intrigued by the article's preference for the web implementation. Yeah, sure: two presentation APIs is too many, but why is the web one the one to keep? The article development seems to make the choice based on user experience, specifically the invocation experience ... "I want to run my browser and then ...." I can't quite say I'm getting that ... personally, I want to do everything from "whatever interface I happen to be looking at when it occurs to me to do something else." Often that's a browser; often that's a command line; often it's some desktop or rich client.

  Life used to be so easy, back when "run anything from anywhere" just meant "every interactive program should provide a '!' command that launches a subshell" ;-)

  Posted by: jrepenning on August 04, 2006 at 09:24 AM

• jrepenning,"two presentation APIs is too many, but why is the web one the one to keep?"I'm thinking that the web presentation is the one to keep because it is the presentation layer that can run on all of those devices that I don't own...Perhaps I am unique in this respect, but I seem to find myself using devices that I don't own (and don't have authorization to install software) on a regular basis.Your obervation about the dividing line is right on target... Disconnected applications have to be very well thought out. What functionality does make sense when the device is disconnected?For example, can you imaging Google Earth in a disconnected mode? Pretty scary data requirements...Thanks for your comments,-JohnR

  Posted by: johnreynolds on August 04, 2006 at 09:50 AM

• Running a pure web app on the uncontrolled devices, installing a WAR into a captive tomcat where you have that much control, and sometimes running the web app in "be a web app, but also sync/cache in background," eh? Tall order ....

  And does it all have to come off the same URL? Seems like there needs to be a redirect here, somewhere (or a change to the browsers to do tha for you, which I think was also off the table).

  Posted by: jrepenning on August 04, 2006 at 10:01 AM

• Yes... a tall order indeed ;-)Disconnected browser applications offer many challenges... which is probably why we don't see them, and why folks like Adam Bosworth always end up requiring changes to the browser itself.I can envision my local webapp redirecting to the remote webapp... but I suppose that I would then need to use a different URL than I would use when accessing the application from a kiosk machine.... That's not too onerous, since I'll probably use a bookmark on my personal devices rather than an explicit URL.Falling back to JohnC's desktop approach certainly would simplify implementation... if I can just get over that "two paradigm" hangup of mine ;-)-JohnR

  Posted by: johnreynolds on August 04, 2006 at 10:37 AM

• I think we could have a local copy of tomcat and configure the browser to use it as a proxy.
  While online , pass request to online url, if offline call local webapp to do the work.
  I thought about it for other kind of apps and, yes, it has 2 advantages.
  First for the developer, use only one technology (web).
  Second, for the user, don't change GUI paradigm.
  Inch up.
  Bye

  Posted by: garidan on August 05, 2006 at 12:41 AM

• check out XUL: http://www.xoetrope.com/zone/index.php?zone=XUIhttp://www.xoetrope.com/zone/articles/article.php?zone=XUI&article=sugar&articleid=123

  Posted by: felipegaucho on August 05, 2006 at 04:46 AM

• Thanks Felipe,I'll check out how XUL handles disconnected apps.-JohnR

  Posted by: johnreynolds on August 05, 2006 at 06:28 AM

• Hmm...I just saw an announcement for something called "SwingWeb".
  Maybe that will cure my "multi-paradigm" woes.Does anyone out there have any experience with it?-JohnR

  Posted by: johnreynolds on August 05, 2006 at 10:18 AM

• fyi John - You should find this interesting...

  http://blogs.sun.com/roller/page/FrancoisOrsini/20060507

  http://blogs.sun.com/roller/page/webmink/20060502

  Still work in progress...

  Posted by: forsini on August 06, 2006 at 05:30 PM

• 
  I would not use Tomcat but Jetty web server instead. As Jetty is full Java, then it could be managed by Web Start also. That's cool.

  
  This being said, I see 2 solutions for your pb, if you want to preserve your application URL. (1) you might modify Web Start to act as a firewall and detect the disconnection to redirect requests to the local Jetty web server. (2) you might develop a extension per browser to detect disconnection and rerouting requests to the local web server, after having starting it.

  Posted by: dmdevito on September 04, 2006 at 05:28 AM

This work is licensed under a Creative Commons License.