At SXSW and AjaxWorld, I had the opportunity to talk about dojo.gfx and native web vector graphics in general. The amazing thing about these talks was the large number of attendees familiar with and interested in SVG, Canvas, and other native vector graphics formats.

It’s still very early, but the interest in collaborative web applications that involve richer, interactive drawing capabilities is growing rapidly. I’m pleased to announce that I am making my slides available online for both of these talks. What is interesting about these slides, even more than the content within them, is that both were created using dojo.gfx. They are great examples of mixing HTML and SVG/VML techniques to create a nice user interface. While there is nothing explicitly preventing them from working cross-browser, I have only tested them on Firefox 2 given time constraints.

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.

Hello,

Writing RPM packages seems to intimidate some, but it can be easier than you might guess. Below, I will:

• point out the online reference RPM documentation
• describe one method of configuring a build environment
• outline a simple specfile (sysreport package)
• describe the process of building the package from the specfile
• introduce a few convenient RPM macros

Here are a few terms:

• specfile a file containing the rules for building an RPM package
• RPM the distributable package intended for the target
• SRPM a special package containing all the source code and the specfile for a given package
• rpm the command-line program used for installing packages
• rpmbuild the command-line program used for building packages

(more…)

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.