SitePen and Dojo are proud to announce a new beta release of Dojo Offline. This release has a huge amount of exciting new functionality, including a full port to Google Gears, a port from Dojo 0.4 to 0.9, and more.

(more…)

We’ve pushed out the beta of Dojo Offline! See the official Dojo weblog for details.

This is it folks! This is the last week of dev for Dojo Offline until we pop the Dojo Offline beta out the door, either later this week or on Monday, April 16th.

Last Week

Last week we finished the Windows installer for Dojo Offline. It comes out to about only 300K! No multi-megabyte download runtimes here. We also continued to fix QA bugs with an eye to the beta launch. The Mac OS X installer was also worked on.

This Week

This is the big week! We will finish the Mac OS X installer, fix important QA bugs that remain and get things into a shippable state, write up good docs, and get a Dojo Offline beta out the door.

The following week, on Tuesday, April 17th, SitePen and Brad Neuberg will be giving the first public presentation on Dojo Offline and creating offline enabled web apps on the open web. The session is at 4:50 PM at the Web 2.0 Expo.

Last Week

We finished a bunch of big tasks last week, mostly having to do with fit and finish and our installers:

* The Moxie demo for Dojo Offline used to take too long to load — it was loading about 27 resources on page load — we optimized this to about 3 resources on page load drastically improving page load time.
* We created about 80% of a Windows installer using an open source toolkit from Microsoft called WiX. Unfortunately, WiX
turns out to make easy things hard and hard things close to impossible, trying to turn XML into a programming language. We abandoned using WiX.
* Instead of WiX, we started back over with NSIS, the Nullsoft Scriptable Install System. NSIS turns out to be far better for our tasks, and the installer for Windows is almost over. This installer does alot on installation, such as autoconfiguring the available browsers to use our PAC file, keeping a reference to older proxy settings so they can be reset on uninstallation, starting the Dojo Offline proxy up on system startup, etc.
* Dojo Offline development was being done on the head of Subversion, but the head is changing too drastically for a planned deep overhaul of Dojo. Instead, we branched from the 0.4.2 branch to a new Dojo Offline branch and migrated everything over. All Dojo Offline development is now happening on this branch.

This Week

Expect to see the Windows installer done this week, automatic restarts done this week (if the proxy crashes for some reason), and the Mac installer done. Also, anyone who would love to volunteer with QA by testing the installers, uninstallers, and Moxie please email me: bkn3@columbia.edu

Last Week

We’re almost there! Here’s a laundry list of some of the code checkins from the last week:

* We now provide a way to give a ‘magic’ domain name that will resolve to the localhost to help in testing in scenarios where the developer is running both the client and the server on the same machine. Polipo, our local proxy, doesn’t read and parse your hosts.conf file for local domain names or use the platform’s standard gethostbyname function; instead, it rolls its own DNS communication for various reliability and performance reasons, which means that it bypasses the hosts.conf file. This can make it difficult to do rapid testing on your own box, which we now provide a workaround for.
* Did much more testing of offline ‘replays’ on Windows, fixing bugs that were found. Offline replays are when we attempt a communication on the network through the local proxy, have it fail becuause the network is down or malfunctioning, and then ‘replay’ this request against the local proxy’s offline cache in order to provide cached results.
* Fixed a regression where we would always print a ‘details’ message in the Dojo Offline default UI even if there were no messages or errors to report.
* Polipo 1.0 came out in the interim; we were at something like 0.9.99. Diffed our codebase against the 1.0 release to make sure we picked up any code changes made in the jump from 0.9.99 to 1.0.
* Fixed bug found in QA: On Firefox/Mac, sometimes if we are offline and start loading moxie, the whole page doesn’t load
* Made sure UI tells user to restart their browser when a web app has been added to the offline list for the first time. When we add a web app we update our PAC (Proxy AutoConfig) file; some browsers don’t see changes to a PAC file made after startup, and will only pickup changes when restarted. Created a way to have JavaScript layer ‘query’ to see if the PAC file has been updated yet — if not, we tell the user to restart their browser. Tested and QAed on Windows and Mac across Safari, IE, and Firefox.
* QA test done with bug fixes: do repeated on off line cyclings with local proxy to make sure DNS names aren’t cached in a wierd way for offline detection
* Created install.bat file for quickly ‘installing’ and refreshing an installation on Windows to aid rapid testing on that platform
* By default, Polipo saves cached files from memory to disk on a long timeout, sometimes several minutes — found source of issue — Polipo now caches new objects from memory to disk within 2 seconds. Before this a bug would occur on Windows where we would hit a web app for the first time, cache it’s offline resources during the syncing process, and then drop off the network and restart the browser to use the app — you would get a cache miss and errors. Fixed.
* Figured out how to have Windows running in Parallels access Mac OS X without having a network connection, to aid in debugging and more rapid development on Windows. I run the ’server’ portion of the Moxie demo on Mac OS X, and access it as a ‘client’ on Windows to test the whole system on that platform. In my old configuration I had to be on the network for the virtualized Windows to see the Mac OS X system, since it looks like a different machine and needed an IP address to resolve.
* Did some important project housekeeping I had been putting off: based on usability testing from about 1 1/2 months with Moxie, the Dojo Offline UI was modified to be much simpler, with less options — this was done as a custom UI inside of editor.html — I’ve now rolled these changes back into the widget.html file to make all DOT based apps have this simpler UI, and have removed a bunch of UI featuritis that was related to being too close to the problem, such as the configuration UI (users don’t want to configure offline options — they just want it to magically work)

This Week

Our dev schedule now includes two extra weeks in April to aid in QA of the system. I will be sending out a big call for QA volunteers to help with testing in the first week of April. I’ll blog more about this on Tuesday or Wednesday of this week.

The goal this week continues to be about reliability and performance. Improving the stability of the local proxy, bug fixing, QA testing, getting the Moxie demo to load quickly because that will be the benchmark that folks will judge the system on, etc. I also expect to start putting together the installers and install scripts, which will be tricky since they need to automodify any browser’s that are on the system’s PAC file settings. Any info from folks on how to do this for Safari would be appreciated — I’ve found some solutions but I’m not happy with them.

Last Week

Last week we did lots and lots of coding on the local proxy for Dojo Offline. Here’s a laundry list of some of the code checkins and QA fixes:

* Moxie had an encoding bug related to new lines being incorrectly serialized during the Dojo Offline syncing process — fixed
* Polipo, our local proxy, was modified so that if it is online and a network error occurs, either from DNS, talking to a server, etc., we automatically ‘fault’, move offline, and attempt to replay the request against our local cache.
* Sometimes, while loading the Moxie page using the local proxy while online with the browser cache cleared, it can take a LONG time or the browser can hang — Fixed, turned out to be related to how we were handling network timeouts
* Create automated build system for Mac OS X and Windows — now, we can quickly push out Mac OS X and Windows builds with a single build command, issued on the Mac
* On Safari, we don’t consistently get Moxie from the offline cache even if it is there - Fixed
* Windows/Firefox: Go off the network, start up DOT, open browser, go to Moxie — “Falling back to using system resolver” - Fixed
* Got the GNU Debugger (gdb) working on Windows, so we can quickly create Windows builds on the Mac and then debug Windows-specific bugs on Windows
* On Safari: “Safari: Connect to codinginparadise.org:80 failed: Host is down” - Fixed with more generic solution to how we handle network errors, noted above
* “Couldn’t send DNS query: Socket is not connected” - Fixed with more generic solution to how we handle network errors, noted above
* Firefox/Mac OS X — go on network, start proxy, go to moxie, clear browser cache, close browser, drop off network, double click moxie link on desktop — browser just sits and spins - Fixed
* On Safari, off the network, get the following when double clicking link from desktop — only sometimes: DNS: couldn’t open /etc/resolv.conf: No such file or directory - Fixed

This Week

The big task this week is to keep driving QA against the local proxy to improve reliability. Lots of the bug fixes above were basically of this type; we are testing the local proxy against Safari, Firefox, and IE on Windows and Mac OS X.

One example is to fix a caching edge case between the browser and the local proxy. Basically, sometimes we want to ‘bust’ the browser cache to really talk to the local proxy, without busting the local proxy cache. This fixes a bug that can occur under some conditions.

Along side this, we want to get ‘automatic restart’ code going for the local proxy. The local proxy will start on system startup — if it crashes for some reason, we want it to automatically restart.

This week I’d like to also hit other fit and finish issues, as well as potentially start putting together installers.

Last Week

Development was a bit slow last week since I was at Microsoft for a few days at their research laboraties and TechFest, and I gave a keynote at Yahoo on Thursday titled “Inventing the Future”. The video of the keynote should be available online this week.

This Week

The big task is the same as last weeks — to continue to refine the local client side proxy. This includes improving linkage between the JavaScript layer and the local proxy to make sure we work correctly when the network is present or gone; pulling and adding resources from the local proxy cache even without HTTP/1.1 headers sent from the server if we are offline; and more. We might also begin to create installers/uninstallers for Windows, as well as code to register the local web proxy for startup when the system starts.

Someone managed to upload a document that broke Moxie — I’ve removed this document from the Moxie database and cleaned up most of the test docs people added to Moxie, leaving just a few. Go ahead and give Moxie + Dojo Offline a try if you haven’t before.

Sorry about getting this up a little late in the day; I’m actually in Redmond, Washington right now to attend a Microsoft research event at their R&D labs. I just got situated at my hotel and found a WiFi network to work from to start hacking on code and post this status report.

Last Week

Last week we put up a screencast showing Dojo Offline and Moxie in action; created a blog post discussing our latest Dojo Offline deliverable and source code; put up our first official release of Dojo Offline (the JavaScript API layer + Moxie — this is an alpha release that does not include the client-side proxy yet); and got a live demo of Moxie running on our servers.

Coding was a bit slow later in the week since I was working on a speech for Yahoo.

This Week

The big task is to continue to refine the local client side proxy. This includes improving linkage between the JavaScript layer and the local proxy to make sure we work correctly when the network is present or gone; pulling and adding resources from the local proxy cache even without HTTP/1.1 headers sent from the server if we are offline; and more. We might also begin to create installers/uninstallers for Windows, as well as code to register the local web proxy for startup when the system starts.

Also, the Moxie demo has been used by scores of people, with lots of interesting sample documents added by folks, and someone found a way to upload some content that breaks when we download it through our JSON data structure (I believe it is a SCRIPT tag that is closed, but I am still isolating the bug). Until then the downloading phase of Dojo Offline for Moxie spins continuously; this is a Moxie bug and not a Dojo Offline bug, which I will isolate this week and fix.

[Note: This blog post is out of date. For up to date information on Dojo Offline please see the official web page.]

Hi folks; lots of news on the Dojo Offline front.First, we have put up a screencast that shows a demo of Dojo Offline named Moxie. Moxie is an example application bundled with Dojo Offline that shows how to use the Dojo Offline framework. It is a web-based word processor that features local storage and offline access. Moxie is now finished for Dojo Offline.

Watch the Dojo Offline Screencast

Next, we’ve finished the JavaScript layer of Dojo Offline. Dojo Offline consists of two major pieces: a JavaScript API that is included with a web application, and which helps with syncing, on/offline status notification, caching of data and resources, etc.; and a local small web proxy download that is cross-platform and cross-browser and which is web application independent. The JavaScript API is now finished, and can actually be used even though we have not finished the local web proxy yet. This is done by having the JavaScript layer be able to use the browser’s native cache if no offline cache is available. This means you can start playing with Dojo Offline right now, with the download link included in this blog post below. Note that using the browser cache instead of the web proxy is only suitable for prototyping and should not be deployed on production applications; it will work with varying degrees of success on Internet Explorer and Firefox, but not consistently on Safari. Higher levels of reliability will only come when we deliver the local web proxy component.

(more…)