Bill de hÓra

I've moved over to Thunderbird and Firefox. Mozilla is now uninstalled; IE's last remaining purposes are to test websites and view XML files. I haven't used Outlook/Express for years now.

The last time I tried Thunderbird I stopped after a few minutes. It didn't import Mozilla mail files; that had to be done by hand (I'm aware that this is not a hard thing to do). Version 0.9 however does have an import tool. The last time I tried Firefox it crashed a lot and felt clumsy. Both apps are much improved. Hopefully this will remove a constant source of puzzlement from my work colleagues, most of whom are using at least Firefox and have been looking at me with some concern in my mail and browsing choices for some time now.

The truth is, as a Mozilla user, features like popup, cookie and junk mail controls and tabbed browsing are less exciting than if you're coming from IE/Outlook. However some things are worth pointing out about the two from a Mozilla perspective:

• In Firefox, right-click close tab and right-click close all other tabs are not beside each other. That alone makes it worth switching, although they probably have them the wrong way around - close tab is on the bottom instead of the top (from right click I close tabs more often than I open). What Mozilla did by putting them beside each other will go down as one of the great UI bloopers.
• In Firefox, opening a new tab puts that new tab in the background. This makes browsing much easier than the Mozilla way of bringing you into the new tab just so you can click back to the one you were on (you almost always want to stay on the original page).
• In Firefox, the home page is a clutter-free wrapper around the Google seach form. Like my many developers, Google was my homepage, so this is good.
• In Firefox, a search bar has been integrated into the menu area to the right of the URL bar. Mozilla used to have to take valuable real estate by using an entire sidebar to show a single seach form.
• Thunderbird when downloading a lot of mail does not seem to perform that annoying feat of displaying mutiple icons in the system tray, which makes the entire taskbar in windows oscillate.
• Thunderbird can be set to spellcheck before sending mail. Outlook has had this feature for years. As a terrible typist, I expect this will be something of win.
• Thunderbird can be set to stop images being loaded into email.
• In both, theme management is much better. I do miss the Orbit theme, but the minimalist in me really likes the 708090 theme.

And these applications are fast. I figure either to boot in a few seconds, on par with IE. Mozilla used to take an age to load (20+ seconds)

The single annoyance: Thunderbird did not import my mail filters from Mozilla. I had a lot of those.

As useful as the features and usability tweaks are, there is something much more interesting about Firefox and Thunderbird, and that is the sense you are dealing with well-polished end user applications and not collections of components. Firefox and Thunderbird represent a new breed of open source projects that are first and foremost, products. They have a clear focus on end users, well articulated missions, and critically, keen brand awareness. It will be interesting to see if and how Mozilla evolves beyond the mail/browser pair into a set of infoware-tools that move beyond the ageing and increasingly less relevant productivity suites. Desktop search, IM, media management, feed reading and music all seem like candidates.

Posted by Bill de hÓra at 01:42 PM | Permalink | Comments (6) | TrackBacks (0)

Required specification implementations from JEP0073.

For servers:

• XMPP Core
• XMPP IM
• JEP-0030: Service Discovery
• JEP-0078: Non-SASL Authentication
• JEP-0086: Error Condition Mappings for servers
• JEP-0077: In-Band Registration

For clients:

• XMPP Core
• XMPP IM
• JEP-0030: Service Discovery
• JEP-0078: Non-SASL Authentication

[fodm: spoonie]

Posted by Bill de hÓra at 12:31 AM | Permalink | Comments (0) | TrackBacks (0)

Using a URI API instead of WSDL/SOAP doesn't neccesarily mean one has a RESTful system. Despite claims, the Amazon API is arguably not RESTful as a result of hiding the method in the URI. For example in the Amazon queuing API has a delete operation that looks like this :

http://webservices.amazon.com/onca/xml?Service=AWSSimpleQueueService
    &SubscriptionId=[Your Subscription ID Here]
    &Operation=DeleteQueue
    &QueueName=[The Queue Name]			

The HTTP method does not seem to be specified. Hopefully an operation with side-effects, like delete, is not going to be applied over GET. HTTP has a DELETE method, tho' given the limitations of some clients, POST might be an acceptable compromise.

Let's not be too quick to jump on Amazon. In general, using URIs to modelling containers is known to be tricky. I'm working on a reliable receive technique for HTTP; a technique for reliable delivery has already gone in production. One use case for these techniques is that one could provide a queuing interface or gateway to systems based on JMS or MSMQ - arguably offering similar functionality to the Amazon service, but with different levels of service. My suspicion in working on these is that there is a mismatch between HTTP and queuing data structures that makes implementation matters less simple than we would like. A queue, well, is a queue. However HTTP URI space is more like a big hashtable than a queue - assuming you have the URIs to hand, then everything on the web is click away.

This mismatch also rears its head in syndication technology - we can think of RSS feeds as a means of generating a list of URIs and putting that list in a well known place. There is an argument that says the data structures implied by HTTP or Tuplespaces can offer more than queuing structures; however that neglects the fact there are a lot of of systems we'd like to web enable and integrate that are based (and happily so) on message queuing technology. Other approaches to container modelling incude WebDAV, but the RSS/Atom "here's-a-list-of-items" seems to be an expedient solution for bridging web and message queuing systems.

Posted by Bill de hÓra at 03:00 PM | Permalink | Comments (2) | TrackBacks (0)

Embed X-expressions into Common Lisp

[underworld: two months off]

Posted by Bill de hÓra at 05:47 PM | Permalink | Comments (0) | TrackBacks (0)

[updated: Michael Jouravlev, the author of the articles was kind enough to propose a fix via a comment. I'll amend this entry more thoroughly to reflect that later.]

The second article of the Redirect After Post series on TheServerSide contains two terrifically bad design choices.

On creating an item:

Note: createItem was originally invoked using pushbutton and POST method. But Struts throws an exception if an action corresponding to HTML FORM does not define a form bean. Because createItem action does not use form beans, the HTML FORM had to be changed to a link. Thus, createItem is now called using GET method.

On deleting an item:

deleteItem action removes an item from persistent storage. It receives item ID from the link on viewList.jsp page. Updating model in response to GET request is against semantics of GET method, but I decided to keep it that way.

While the purpose of the article is to demonstrate a technique to avoid double submits from a browser and not neccessarily appropriate application design, using GET to obtain a side effect is fundamentally bad practice. The technique itself works, but is of limited use - among other things, it appears to depend on a bug in the Internet Explorer web browser. There are more direct ways to solve the problem.

In fairness to the author, the problem he's tackling is a real one and it seems he is aware of the issues. Yet it's difficult to imagine an article about Java that would pass technical muster if the author decided to publish deliberately bad code, for example, swallowing exceptions or changing object state as a result of calling a getter.

Taking the two the articles together, it's not unreasonable to conclude that the forest is being hidden by the trees insofar as the details and nature of the web framework is affecting an ability to produce a decent application.

Making a web framework architecture fundamentally reliant on state when the underpinning application protocol is stateless seems to put developers in the uncomfortable position of making bad design choices in order to avoid dissonance with the framework. Hiding statelessness in a web system appears to be a design guff on a par with that of long running transactions, network transparency or synchronous RPC. Most Java frameworks are based on the Model View Control pattern, but articles such as this one suggest the pattern is out of context on the Web. More recent frameworks, such as WebWork and Jave Server Faces attempt to elide the details of HTTP from developers even further, which may be storing up trouble for the future.

Posted by Bill de hÓra at 09:58 PM | Permalink | Comments (2) | TrackBacks (0)