Pseudo-Threading: Multithreading in the Browser

You know AjaxPatterns? It’s a wiki about Ajax. Anyway, it’s now fully open for editing, but I’ll post more about that later. Right now, this post covers a particular pattern that’s been sitting in eXtreme Stub mode for some time, and has now got a little flesh to it.

Pseudo-Multithreading (mmmm…just rolls off the tongue) is a Performance Optimisation pattern to make input smoother. Now that the wiki’s open, you could even contribute some info if you’ve used it.

(The links below don’t work as it’s a straight HTML copy.)


  • Ajax Apps are single-threaded. Browsers don’t allow scripts to multithread, and nor does Javascript have any built-in support for it.
  • Most Ajax Apps accept user input.
  • Some Ajax Apps require complex processing in the browser. If the thread of execution is busy performing such processing, users won’t be able to perform input.


Using Scheduling, a processing function is called once in a while, incrementally processes a bit more of the problem, before yielding. Instead of solving the entire problem at once and returning, the function maintains a “blackboard” object and continuously works on it until the problem has been solved. This “blackboard” object is optional and may be something that forms the eventual solution, or just a copy of the original problem and an indication of what to do next.

For example, imagine you’re implementing a Portlet, a real estate advertisement providing a mortgage rate calculation. The calculation requires you to run a simulation, calculating the value at the end of each day for a year – a loop of 365 calculations. If you do it all at once, the user won’t be able to do anything during that long period. So instead, you break it into chunks of 10 days at a time. At the end of the first chunk, the blackboard indicates the situation after 10 days. At the end of the second chunk, the blackboard indicates the situation after 20 days. At some point, it will reach its target, 365 days, at which point it will probably call a callback function or just handle the result directly, e.g. paint the result on the user-interface.

It’s convenient to handle this in an object-oriented fashion, where the blackboard data and the processing function belong to the same object. The object is basically a Strategy or Command object (Gamma et al) – it has a “run()” method that does a little bit of processing, and sets values as attributes of itself. In the above example, we have a Calculator object with a run() function that performs the 10-day simulation. begins by reading the daysSoFar attribute, calculator.daysSoFar and the valueSoFar value, calculator.valueSoFar. It then simulates the next 10 days, and updates those attributes. Calculator might also include additional attributes too, such as: the number of days to simulate per run() invocation; the completion condition (which could be a function itself, or just a value such as number of days); a callback function to call upon completion.


Thin Client

“Thin Client” Ajax Apps delegate any complex processing to the server. Probably more network and server overhead, but less CPU cycles devoted to processing and more to user input.

Related Patterns

(TODO Patterns like Live Search, Portlet, and Live Form should point here.)

Real-World Examples


The Ajax spreadsheet NumSum, continuously recalculates cell values, using Pseudo-Multithreading.

Got Captcha? Antispam on AjaxPatterns

I’ve been blabbing on about how I’m going to open up the AjaxPatterns wiki for as long as it’s been online (about a year), blah blah, talk is cheap. Anyway, it’s a few steps closer now. The main issue has been protection against spam – some entrepeneurial folks behind numerous proxies have discovered there’s a good niche market among Ajax developers for fake watches and cheap pharmaceuticals, and AjaxPatterns is just the thing for their cunning Long Tail marketing strategy. I wish these measures weren’t necessary, and they certainly won’t be foolproof, but hopefully they’ll let us grow a bunch of useful Ajax content without too much interruption. After The Ajax Experience, I realised how much more there is left to document and how much people want to hear and say.

So these are a few things you’ll see at AjaxPatterns.

  • Captcha – just implemented. Let me know if you have any problems. Unfortunately, it does go against accessibility, but contributors who have difficulty with it could always mail me contributions. Hopefully, mediawiki will incorporate captcha at some point, the kind of project where the resources for a more accessible solution would make sense. Mail me if you want more info on the implementation.
  • Links to book version Implemented, but not live. Each pattern page will link to the corresponding book version (well, a close-to-complete draft). Even if a spammer messes with the pattern description for a short time, there will be a permanent link to the corresponding description in the book.
  • Word/URL BlackList Based on Spam Blacklist. Sorry, no examples involving discount Rolexes.
  • Backup strategy Another measure is frequent snapshots of the whole thing (that’s always been there) .

“So, Jesse, Is Ajax a Pattern?”

… That’s the question I finally got to ask the man who gave Ajax its name, following Jesse James Garrett’s keynote last week at The Ajax Experience. I consider Ajax a very standard, uncontroversial, example of a pattern, so I’ve wondered why it wasn’t introduced as such, in the original Ajax paper.

Jesse said he’s asked the question quite a bit. He didn’t answer the question directly – there wasn’t a “Yes” or a “No”. Essentially, he just made the point that patterns mean different things to different people, everyone has their own idea, etc. In other words, I think he either doesn’t want to get bogged down in the debate or doesn’t consider it important.

At first, that seemed rather anticlimatic, but on reflection, I can see his point. He mentioned in his talk how people (of a certain kind, I guess) mail him saying “I wrote this app in 2000, it uses IFrame yadda yadda … Is it Ajax?”. So he probably has enough trouble with the definition of Ajax to worry about the definition of patterns as well. Moreover, he’s a consultant, and probably talks to high-level managers who wouldn’t know a pattern from a shell script.

So it’s understandable from a pragmatic perspective why “pattern” isn’t used in the original definition of Ajax, even though Ajax fits the mould perfectly. However, it is a shame for software, and industry at large, that patterns aren’t the standard way people think about designs and processes. Framed as a pattern, a high-level architectural style like Ajax can evolve quickly, as people begin to consider examples, forces, rationale, and all the other standard attributes of a pattern. Furthermore, people can ask about the role of this pattern in the entire ecosystem of patterns. What are its alternatives and how does it stack up? What are the lower-level patterns that should be solve questions opened up by applying the high-level pattern?

That many managers don’t get patterns leaves a lot of potential for improvement within organisations. An open wiki of interlinked organisational, technical, usability, etc patterns should be an asset to any company. As explained in this visionary paper by Jed Harris and Austin Henderson. The 2020 scenario suggests how patterns might be navigated in the future.

Then she puts a probe into the guise and begins looking for the patterns that the guise uses to model market response to Heavy Metal.* Her office shows her the internal organization of the guise as a network of nodes whose size and clustering reflect how much they contribute to the guise’s current display. Each of the nodes is a small view of the associated pattern, showing its current state; if she focuses on a single node, she can usually tell how it is contributing to the display. Olivia thinks of this display as a “sea of nodes” because the ripples and swirls remind her of flowing water. She swims through the sea, getting a feeling for how Fred has put the guise together, and how the guise itself is interpreting the current behavior of Heavy Metal’s customers. After a little while she zeros in on the service and support patterns. By suppressing the contribution of some patterns and looking at what changes in the display, she eventually finds a pattern— Service is a Feature— that seems to be most involved with the aspects that have been bothering her.

134 Ajax Frameworks and Counting

I’m here in SF for The Ajax Experience, talking about design principles and patterns for Ajax (big surprise!), and one of the things my presentation will point out is the importance of libraries and frameworks in implementing Ajax patterns. Ahead of the talk, I just did a quick count of frameworks and libraries on the wiki. Turns out there are 58 in pure Javascript and another 76 with back-end support in PHP, Java, or whatever. This includes 13 for .Net, and no less than 22 for each of PHP and Java.

Overall, that’s 134 Ajax frameworks and libraries out there, many of them under a year old! It’s true that a few of the pure Javascript libraries are things like Drag-And-Drop that have been around a few years, but only a few of those. The rest are all-encompassing, like Dojo, or related to remoting, like ACE, or related to XML and DOM manipulation in a manner closely associated with Ajax, like logging and effects libraries.

When I transcribed the frameworks to form an appendix for the book, there were about 90 patterns. That was in December. So roughly 45 new frameworks since then, about one every three days. Nice going! Stuff like this makes life a lot easier for developers, no matter what they’re approach to Ajax architecture. Even if a developer doesn’t want to go near Javascript with a ten-foot pole, they’re still going to reap the benefits from a server-side framework (Rails etc). Furthermore, the server-side framework is going to reap the benefits of all these pure Javascript libraries – a number of server-side frameworks make use of Dojo, Scriptaculous, and Mochikit.

Patterns and frameworks go hand in hand. It’s not that a framework “makes patterns”, as some sales reps like to imply, but frameworks do support particular patterns. Most GUI toolkits, for example, are based closely on the Observer pattern. Java’s IO library is based on Decorator. In the case of Ajax, there are libraries like Scriptaculous which map closely to particular patterns, like One-Second Spotlight. The best reference on this stuff is Ralph Johnson’s visionary 1997 paper, Frameworks = Components + Patterns (Comms of the ACM, October, 1997).

Mix ’06 and Ajax Design Principles

‘Tis Goud reports from Mix ’06, Microsoft’s web bash currently happening in Vegas. One of the presentations focused on the most important thing about Ajax: Usability.

The session started with referencing two sites with information on:

Thomas’s guidelines were the first serious look at Ajax usability and a big inspiration for the Ajax Patterns.

The patterns and the principles were apparently distilled to this list:

  • Feedback
  • Predict
  • Preserve
  • Share
  • Controls
  • Separate

If anyone has more detailed info on this discussion, please let me know!

As it happens, the third chapter of “Ajax Design Patterns”, the overview to the patterns themselves, explicitly identifies principles on which the patterns were based. Principles and patterns go hand-in-hand, so any pattern language I’ve worked on always comes with a set of principles, an explicit reference point for people to grasp where the patterns are coming from. You can even (with some energetic hand-waving) look at the patterns as being defined around the principles: “These patterns are written such that if you follow them, your system will adhere to these principles”.

Anyways, the principles are broken into two groups: Usability Principles and Software Design Principles. Maybe I ought to podcast them sometime.

These are the Usability Principles for Ajax.

  • Follow Web Standards
  • The Browser is Not a Desktop
  • If it’s Different, Make it Really Different
  • Provide Affordances
  • Smooth, Continuous, Interaction
  • Customisation
  • Make it Fun

These are the Software Design Principles for Ajax.

  • Embrace Javascript
  • Accept Workarounds Where Necessary
  • Tame Asynchrony
  • Develop for Compatibility
  • Reduce Bandwidth
  • Deal with Latency
  • Partition into Multiple Tiers
  • Go Easy on the Browser
  • Practice Graceful Degradation

It’s funny. The very first thing I think of when I see stuff like this is along the lines “SHOW ME THE PATTERNS!!!!”. I’ve got no patience for motherhood statements like ‘Tame Asynchrony’. But the reason for this annoyance is because you usually see these kind of principles in the absence of any explanations, examples, or patterns. Once it’s apparent that the principles are merely a background to more concrete advice, their presence has been justified.

SAG Ajax Patterns Review 3 – Call Tracking, Distributed Events, On-Demand Javascript, XML Data Island, Browser-Side Templating

Following from previous posts, here’s my notes from the third SAG (Uni. of Illinois CS Dept) workshop/discussion on the Ajax Patterns. See the initial post for a background on this series.

Note that there was a “2.5”th workshop on HTML Response, JSON Message, XML Message, etc – it happened, but there’s no audio, so I decided to skip it wrt the numbering (the present workshop is really Workshop 4).


Feb-20-2006 Third Ajax Patterns Discussion


Use the "hidden version" versus the wiki [MM Guys, definitely the hidden version - the wiki more or less stopped a few months ago.]

Mention of O'Reilly Rough Cuts - Takes a while to make something ready, do you want to deny people the advantage of seeing it?

5:00 Intros

5:30 Call Tracking

[MM btw On the wiki, this was the first full pattern I wrote and it's pretty awful. Virtually rewrote it for the book. (The book content should eventually find its way back to the wiki, but maybe something more like the book format, with Wizlite for annotation.)]

XMLHttpRequest Call didn't address the bigger picture Call tracking highlights the async nature of calls - several ways to track it. Hand-drawn, crude, diagrams.
[MM These diags are mockups for the O'Reilly illustrators] Could have global XHR object - but then limiting multi-processing Is this pattern worried about resources or reliability? - More about [TODO Clarify it's about Call Tracking.] From the wiki version, seems like resources etc. Ambiguous.

11:00 When start thinking abt async communication, can think about reflecting on the message. (??)

============================================================ 12:00 Distributed Events

Fits quite well with Call Tracking [TODO Check Related Patterns sections, add refs?]

Single object/entity might have interdependencies

Clear that it's like an Ajax version of publish-subscribe - "Distributed" name confusing, "terrible". - Sounds like multiple servers (no). - Using patterns like Observer, a different name referring to the same thing. - But he's focusing on the fact that the events are distributed. ie in Java usually listeners are all in the same ?space. - Yeah it's kind of distr'd events, but the problem doesn't fit in with it.

Solution didn't seem to get into the details. Focus went back and forth between events and. [TODO Observer pattern sidebar]

Interesting, the problem is a really different context. There's no vocab for that sort of thing, he's trying to create a vocabulary for it with this pattern. - Except that in MS case it's transparently distributed. Hook docs together, doesn't matter if docs are on same machine or not. Built into that (platform). Probably slower than JS. People have been building distr'd events systems for a long time. Interesting that it's become a big part of these JS systems. - So maybe problem/forces should say more about the complexity of the communication

19:00 browser-to-browser is not distrib'd. [TODO Clarify that it's the same browser.] - Last line "should be clear ...": Using a generic interface rather than making a specific interface. Could have model object with a list of views. Instead, we say the model has a list of dependents - Well yes, it's another level of indirection, but could have implemented update as a list of views. But the main thing is, we have a generic interface - you don't know if the dependents are views and what they'll do with it. If you know they're views and you call redisplay(), you'll know they'll redisplay. - Had the same feeling - less about extra layer of intermediation and more about the fact it's generic. - [TODO Reword] - Examples: APIs where there's a central mediator. Java listeners don't have a central controller, every event listener has its own [TODO Decision - central manager versus Java-style autonomous where each object maintains its own listeners. (See below.)] - Decisions: History or state. cf Memento pattern [TODO Ref Mememto (or sidebar)]

Enjoyed this discussion. Issues about reflection or whether interfaces are generic to the problem you're solving. As the event mechanism becomes more complex, tend to genericise. The event handling becomes the focus, the architectural locus of these dist'd environments. Temptation to overload the event mechanism - the idea of reflection comes in, interesting that we don't have the vocab to talk about it.

Tradeoffs - "better solution" by adding a layer of indirection. But that comes at a cost.

I think the heart of this pattern is "something changes, something then notified". Key is for Observer, should be named after what happened to the subject. If you have a system where you're calling your observers to go do something ... (different type of events). Events are always events relative to some subject, whereas if going to have some central repo with dictionary mapping subjects to listeners. Actually a fairly minor issue, but seems bigger because not addressed. As events get more complex, tend to centralise it [TODO Also depends on sophistication of inheritance and delegation mechannisms ... not so great in JS, which pushes toward centralising]

33:10 Observer mistakes: Forget to (un)register observer, forget to notify observer, forget to declare observer's handler. Some mistakes easier to catch than others, for me the ones that take longer are when I forgot to register it, esp if only in some certain conditions. From HotDraw, learned it doesn't pay to try to be efficient. e.g. Drag figure around a screen - must redisplay, therefore must be real fast, therefore didn't use observer. So easy to make mistakes when mixing those mechanisms (observer and direct call). Became a lot easier when committed to using observer for everything. [TODO Mention this - tip:]

There's a lot you could say about it, not sure author wants to say it. Good purpose: How to convert distr'd events into that style. Can see a lot of people doing it the stupid way - each display element asking the server if something's changed. [TODO Flag this risk, probly in Decision about central management?]

Code example: Show picture (e.g. interaction diagram) [TODO Diagram]

============================================================ 38:45 On-Demand Javascript

Just-In-Time JS Not convinced of author's motivation for this. Would have to be huge amount of JS to worry about it - it's nothing compared to an image. But I was excited about it for other reasons, could have dynamic behaviour depending on the user/context. [TODO Mention how images are different, they load in parallel and user can begin interacting beforehand. Can't say same about JS.] [TODO Emphasise the "behaviour messages" idea as well.]

Need to give performance reasons, could do with an eg in 2-3 sentences Also useful for cross-domain. "Conventionally best practice has been to include JS unobtrusively" [TODO Reword/elaborate if nec Maybe "best practice is ..."]

Should have a pattern for modularising your system [TODO More background info on this, if not separate pattern.]

Near the end of the Solution Variant: Question - What does it mean to add new members to the DOM? [TODO Clarify ie that nothing will actually happen.] Javascript Response - Reword to "Behaviour Message"

Didn't feel that I knew how to do it. Got the big picture, but not the details, even though lots of pointers. If author wants me to implement it just by reading the pattern, needs more details. - But I never feel like I can do anything unless I try it. [TODO Check (the book version has updated this, check that).]

Interesting if browsers could do this automatically. Cache JS. [MM Caching addressed in latest book version.]

Question on debugging: What if run eval(js) - if you look at src for the original page, it won't be there. How will you find those definitions when you're in the browser? That could be a good reason not to use it. [TODO Discuss Venkmann-handling (should work ok).]

============================================================================== 55:30 XML Data Island

Have a group of data you want to do something with - bring the XML in, display the table etc from that, and you still have the data.

What's the motivation of having it in XML? - They do say that - "could have a custom data format" etc.

Interesting. Stick an entire chunk of XML, which is gibberish to the HTML, but can still use it.

"Even without these browser-specific technologies ...", so the author thinks XSLT goes along with XML Data Island. - Then you do get this agreed-upon standard for doing these transformations. - HTML has a schema. - Ah but there's this special XML tag. Best thing is for the browser to ignore it - they can all ignore it in a portable way. (Laughter.) - Some people here speak other languages - we're all used to hearing a language we don't understand and we all ignore it - common human reaction, and somehow our programming languages don't do it. Only thing that's advanced enough to ignore things it doesn't understand is HTML. - Ajax is defiantly utilitarian - unrelentingly ugly and people just plow ahead. One thing now is that org's like Google can pay people to plough through the ugliness - crud to deal with, browser dependencies

============================================================ 1:05 This pattern answers why using XML. Ajax apps so dynamic, talking to the server all the time. - With HTML, could convert on the server [TODO Why not server-side XSLT] - Mentions you can offload work - Don't want the GUI to be hard-coded into the server. Story is weather info - just has to tweak the XSLT - doesn't change the XML coming from the weather place. Your portal can display it different from anyone else. - Fits with web services - cf Stylesheets [TODO Good to have links to tutorials on XSLT. Chiliplop pattern language (?) Book on XML patterns, never finished. On website.]

============================================================ 1:12:30 Browser-Side Templating

Didn't see any templates I really liked, even though should
be do-able.  Authors thinking it makes life easier for web
developers, I don't know.
  - My guess is that it makes life easier ... because half of
    them are below average, below-average programmers like
    when you can cut-and-paste etc
    [MM Surprised it's seen as a cut-and-paste technique -
    really just a means of separating presentation from
  - With JSP etc, can still let a web designer work on the
    [TODO Explain why - ie to keep the HTML dependence in the
    web tier]

SAG Ajax Patterns Review 2 – User Action, Scheduling, Web Service, REST, RPC

Following from the previous post, here’s my notes from the second SAG workshop/discussion on the Ajax Patterns. See the earliest post for a background on this series.

Feb-2-2006 Second Ajax Patterns Discussion

“We should set up wizlite “sag” group for annotations” [MM For the benefit of others, the online book draft version uses Alex Kirk’s Wizlite.] Wizlite – is it Ajax? [MM Yes, Alex Kirk’s a prolific Ajax developer and writer]

Wizlite – can you trust the data on all these things to stay online [MM Backup solutions like openonomy, part of the argument with these Web 2.0 things is they host it, but you own the data, so you can in theory point a backup service to it and at least you’ll always have the raw data. As for privacy, not much you can say about that (although, in theory, Ajax lets you host encrypted content- see the Host-Proof Hosting pattern). Also, some free content is available, then removed.

Maybe will go down when the book is published [MM I know it was a joke, but just to let you know, won’t†happen. It’s a CC license, and a big factor in going with O’Reilly was being able to keep the wiki online before, during, and after. Interestingly, O’Reilly didn’t have the Rough Cuts program going at the time, but they presumably had been planning it.]

Author had some auditory issues, need to fix that. [MM Thanks, this mp3 worked out better. The first one was fine too once I listened to it with better earphones. Given the quality of my own podcasts, I certainly can’t be a critic here. BTW I think it would be great if the SAG talks were actually linked from a feed. To me, this is the best kind of podcast you can get – it’s zero effort – a meeting that would have happened anyway. (Unlike, say, me rambling about Ajax, which is not something I normally do spontaneously)]


10:50 User Action

So what is the User Action pattern? – What’s the proper way of handling user actions? – “User Action” is more of a problem than a solution. More Event Handler or Callback. Names are typically solutions. Or does a JS programmer call it that? [MM No]. – Rather call it Listener than Event Handler if that has a narrower connotation. – Depends on what people really call it. – But better names come along too, e.g. “Ajax”. – Listener is kind of Java-ish, and JS and Java don’t have much in common other than the name. – The “Java” in “Javascript” name was marketing-driven, a misnomer. [TODO Mention ECMAScript/Javascript distinction in conventions section] – => Suggestion to author for rename

Implies you’re not going to see that event loop, it’s invisible, it’s probably more in the virtual machine. – If doing distr’d programming, end up with lots of loops. Difficult to integrate different packages. If all buried inside the language, could be better because no incompatibilities, but could be worse because it’s invisible. – So events are part of this language. [MM Yes, part of the browser’s DOM implementation]

OK, issues – Not specific to this pattern, but author discusses incompat’s between IE and Firefox. Should be some mentioning about this. [TODO Check pattern mentions libs and deals with this in general terms. Note that intro will discuss how incompats are handled. Mostly, the answer is “Use a library” and that it’s beyond the scope of this book – refer to a JS/DOM book instead. Also, note that I only address IE and Firefox directly.] – Prototype library deals with this. – IE7 uses XHR natively. [MM True, though not a huge deal, before you just needed a factory function. The bigger question is whether they behave the same] – Code – redefine the event handler – is that common? Wouldn’t normally do that. [TODO Indicate this is rare, possibly scrap the Decision. Note: This is indeed somewhat rare]

Could people write a User Action – Just showed onMessageMouseOut or whatever, needs to at least show the outline of the function [TODO I think the request here is to show the signature of onclick, onkeypress, etc. Except they’re all the same – onclick(ev), onkeypress(ev), etc. Need to clarify this in the solution] – Interesting that not compatible across all platform – Couldn’t you abstract out differences between events [TODO I thought that was mentioned, including the quirksblog et al contest, check it] – Interesting discussion on p5 about dynamically .. – Upon seeing that, and if he feels that way, scoring this as a variant of Observer would be an interesting way to go. – That section was a bit confusing. Third parameter was confusing. – How often do you need to have >1 event handler? Not very often. And can always have a composite handler. [TODO Mention that.] – JS event mechanism involving strings e.g. “onclick” for the event handler. Neat but refactoring side of me starts to worry. [MM Could say the same about onclick … in JS x.onclick is equivalent to x[“onclick”].]


29:00 Scheduling

What is it? – As the author puts it, running something at a time in the future or repeatedly. – Another use of event handling. And that’s one reason why “User Action” is better than “Event Handling” [MM That’s basically the rationale I used, could still be “UI Events”] – The vocab is tricky because the overall JS vocab and ideas are still emerging. – Maybe some background on JS event handling is available in the earlier section. [TODO No it’s not. A little in the tutorial but no. Needs sidebar perhaps.] – Is the author assuming JS? [MM Assuming basic knowledge. I suspect most readers have done a little hacking with it, the kind that was used in pre-Ajax style web development.] – Seems like it’s assumed. – But sometimes seems to assume reader doesn’t know anything about JS. [MM Unfortunately, Ajax is so all-encompassing that it’s a tricky issue, and the group of people who could benefit from these patterns is also quite wide. So it’s been a juggling act, but I’m really assuming some basic web development, and not necessarily any general GUI development (ie there are plenty of people who’ve programmed PHP for 5+ yrs, maybe since high school, and have never done anything like Swing).] – Only has example of one-off. Not for repeated event. [TODO Check that. (Solution itself includes that, but maybe reference it from examples, or reference other examples that use it eg Live Search).] – I thought it (JS) was supposed to be object-oriented – As much as it’s like “Java”. – I saw that JS is a prototype-like language in the Self tradition. [MM True. Each object has a mutable “prototype” property. We still need to work out how to fully harness it] – Could also have network events [TODO Sidebar: Also point out other events: XHR, onload/onunload] – Worth mentioning that the timers are not really timers, I’m not going to run my pace-maker using these timers [TODO Precision of timer]

===================================================== 41:00 Web Service

Author provided it even though not on the wiki (as with Ajax App)

Quite short and for being an important pattern, it didn’t seem to be very detailed. So what is Web Service? – Just seems real simple, what the Ajax .. is going to call on the server. – Uses HTTP protocol to pass parameters and bring back data. Could use SOAP, whatever. – It’s a Context, not a pattern. I’m not sure how serious I am about that, but … – Problem: What will the Ajax App call on the Server. – Important to have a web service, just not sure (??if need it as a pattern). – Name is ambiguous (because of SOAP etc) – Well that’s what there are other patterns for eg REST and RPC. – Part of the problem is there isn’t much content to a web service. The hard part is working out what all the messages are, what to expose, etc. – Even when CORBA came out, we felt like, this is old-hat, just trying to standardise what we’ve been doing, etc. – Want to have layers – CORBA, COM, components, Web Service is just the latest in a long line. SUN-RPC (early 80s) was already a standard. – This not only doesn’t tell you how to do these hard issues, but doesn’t…. I would like to see something like: Just because decided to do web service, problems aren’t over. Only just begun. Have to decide on (etc). People want freedom from choice. One reason people like SOAP, REST, etc. [TODO Mention that] – Also, why did web services arise that way? Why not a custom service on port 1065? Why HTTP? [TODO Sidebar? Forces?]

===================================================== 53:10 RESTFul Service

  • Main distinuishing factor bn REST and RPC: REST uses standard keywords for communicating to services. He has interesting anecdote on Google (Accelerator).
  • The idea is if everyone starts following REST, documentation is minimal.
  • “Motivating REST” – He does say important things like there are going to be web crawlers, caches, proxies, etc. So how can you make sure people’s assumptions are met … [TODO Check this is emphasised enough] And I think that’s a big part of REST. [TODO Use the browser as an example, ie type URL makes it perform a GET request]

What do you wish you had in here? – No (I didn’t understand REST from this). – REST = Non-SOAP procedure call. – I’ve heard people say you can use SOAP in a REST-like way [MM Yes, mentioned in “RPC Call” pattern and also in the RPC discussion in the REST solution] – How is this different from a standard form submission? [TODO Sidebar or explanation comparing to std web call? e.g. REST usually returns XML] – Normal web form submission is REST automatically, although one of the things is you want POST to be idempotent. So when you POST, you’ve made a new object. ie Put an ID on the form, so when you POST it says “I’ve already seen this. You’ve sent me this order already.” So won’t put in two orders. – Okay, I was going to ask this … using the URL as a piece of the environment? – No, not the URL. Cannot do it with the URL. The URL tells you the object that you’re posting. – Points to examples in Solution. But these aren’t RESTful [TODO *** Make it a lot clearer that these these match examples aren’t necessarily RESTful!!! I think these might have set the stage for general REST confusion!] – Football service [MM Incidentally it’s Aussie rules :->] – Matches==Games [TODO Change to “game”, good enough for everyone] – I think REST would be good for CRUD, but not sure for transactions. – Well, TX’s are more difficult. Have to make an object that represents the TX, and that’s how businesses work. “I sent you the purchase order, etc”. [TODO Be more clear on this] – Author should describe something outside CRUD. [TODO It’s already there in later sections, but maybe discuss it upfront?] – Was looking forward to learning about REST, but still left wanting more. – The important people here are those who don’t know REST, hence probably needs more content even though it’s already long. [TODO Consider what to add/change] – TODO A REST and RPC FAQ Sidebar – e.g. Can RPC be RESTful?

===================================================== 1:13:55 RPC Service

  • Package up params, unwrap etc. There’s a bunch of ways to do it and he talks about them.
  • Call-By-Reference. URLs can be your references [TODO Mention that]
  • With REST. A lot of things you could say. e.g. Make up all the arguments in the URL. But if you have side effects, that doesn’t work. The side effect operations that aren’t idempotent, e.g if you’re doing SOAP, args will be passed in the POST message, so the URL isn’t really a resource.
  • Pretending you can treat the world as a bundle of RPCs, have to cope with lack of availability, errors, etc, which make RPC unreliable.
  • Which is why REST is successful. What if someone moves a page?
  • Would be nice if RPC was possible, but it’s just not.

1:22 Next time: Patterns after RPC Service?

Ajax Patterns in the Pattern Community Radar

I’m pleased that seems to have entered the pattern community radar in the past couple of months (or maybe earlier, but that’s the impression I’m getting) …

Workshop on Ajax Patterns

Ralph Johnston (of GoF Design Patterns fame) runs a regular patterns reading group/workshop and they’ve been looking at the Ajax patterns. Fortunately, they release the discussions online, which is a great, if unexpected, source of feedback for me! (I had some volume issues and need to listen again after pumping up the MP3s, so I won’t comment on the content yet). The discussion is a mix of general Ajax talk (most participants are approaching this as Ajax programming newbies) and critical analysis of the patterns.

  • Directory of all pattern workshop MP3 (where I assume you’ll find a second workshop too in a few weeks).
  • Direct link to the discussion:
  • (which I won’t link to directly because a future version of WordPress might incorporate it into my podcast feed :-).

Brian Foote: Calling a pattern a pattern

(I’m using this as a springboard to rant on some general pattern stuff …)

Pattern veteran Brian Foote (also in the discussion above) says that JJG’s definitive Ajax article is “quite pattern-like” and apparently concurs with James Governor’s assertion that Ajax is a pattern. Of AjaxPatterns, he says:

Now, Michael Mahemoff has exhibited no compunction in calling a pattern a pattern. Ralph Johnson pointed out this website a few weeks ago for a forthcoming book on Ajax Patterns. It is tastefully rendered, and quite engaging. I commend it to the reader’s attention.

Yes, Ajax has always been a pattern to me. In the notes for last April’s Ajax podcast, I referred to it as an “architectural style”, which I use synonomously with “architectural pattern” (other examples would include “MVC”, “Blackboard”, etc; I think I originally got this idea from Buschmann et al’s System of Patterns V1). A few months ago, I bit the bullet and added an “Ajax App” pattern to AjaxPatterns. Not all pattern languages need a root, but it makes sense in this case to have something that ties everything together.

Is “Ajax App” a pattern? I say it is because it’s a well-proven solution to a recurring problem. Some say that patterns should provide some insight, and Ajax App is just too obvious a solution nowadays to call it a pattern. It would have been fine for JJG to introduce “Ajax App” as a pattern in early-2005, but what’s the value of an “Ajax App” pattern in the enlightened era of early-2006? I would mostly agree with that if the “Ajax App” were published in isolation. But it’s not. It’s published in the context of 68-odd patterns on all things Ajax, as the pattern that holds them together, and many of the patterns refer back to it. It’s a high-level, architectural, pattern, which can be decomposed into lots of smaller patterns that are also documented. It has the essense of being unobvious, even if the buzz of the past year now renders it obvious.

Another way to say it: I’m not really comfortable with the argument that patterns must be unobvious. In some contexts, there’s still many benefits to gain from using a pattern construct to document something that may actually be obvious. I emphasise this because it not only explains why “Ajax App” is a pattern in AjaxPatterns, but also XMLHttpRequest Call, Display Morphing, etc. They are obvious things to do because they fall out directly from the technology … What else are you going to do with an XMLHttpRequest but issue a call??!!!! But just because they are obvious, doesn’t mean we can’t document them. They completely integrate into the structure of the overall Ajax Patterns language, with lots of useful links to and from them. They can completely be described by the standard pattern notations. They give us a suitable, distinctly named, easily discovered, container to elaborate on the technologies involved, the decisions you have to make, and so on. Which is why you’ll find XMLHttpRequest’s API in the XMLHttpRequest Call pattern, and an overview of the DOM in the Display Morphing pattern.

For the record, I’m also not comfortable with the argument that patterns must be proven. Again, I think the argument for provenhood comes from a well-intentioned attempt to keep the patterns relevant and useful. But I’d rather lay out all the patterns on the table, present whatever evidence exists, and let the reader decide how they stack up. For that reason, you have some patterns like Host-Proof Hosting that are unproven, but promising enough to point out. Again, they fit right into the structure, they are easily documented with a standard pattern structure, and they are a suitable easily discovered namespace to elaborate on the concepts as well as facilitate a discussion of whether it’s worth implementing, and

I’m not a “pattern theoretician”, so these ideas perhaps don’t hold up to current thinking. I discovered early on that the patterns community generally avoids too much meta-discussion on patterns and I’ve always respected that view. My PhD never defined a pattern as a “vector of fields 1..n” or a pattern language as a “directed, acyclic, graph”, even though some academics felt it would have been the right thing to do. I take a pragmatic view of patterns – “Are they useful or not” is really my main interest, and I think that’s reflected in the comments above. I don’t mind if you call “XMLHttpRequest Call” a “guideline” instead of a “pattern”, but I think you can see why I choose to call it a pattern – it’s documented that way and it happens to live within a larger system of patterns.

All this comes down to fuzzy thinking instead of strict dychotomies – the same reason I often talk about “how Ajaxian” a system is, rather than “Is it Ajax or not”. Same for a pattern – “how pattern-like is it” rather than “Is it a pattern or not”? I find strict definitions futile, which is why you’ll usually find me disclaiming and apologising profoundly whenever I utter one.

Erich Gamma

From Brian Higgins:

I’ve been working on some Ajax stuff lately and this morning I was complaining to patterns guru Erich Gamma that I hadn’t seen any good design pattern resources for Ajax. He pointed me to this site which looks good: Would have never guessed that one!

Interview with Wally McClure

Not specifically patterns, but I also want to point out that Wally McClure from the ASP.Net Podcast recently interviewed me (fortunately for me not about ASP.Net, which would have been pretty brief!). I’ve had various mail conversations with Wally, who’s writing a book on Ajax and ASP.Net, so it was good to catch up and talk Ajax. Unfortunately, we had some skype issues, so we didn’t end up talking too in-depth. (BTW Both Wally and I had Skype issues. Is Skype seriously ready to be the telephone platform for the next decade? Seems way flakey and lacking in support to me! I submitted a detailed error report a while back and received nothing, despite the fact that I pay around $50 a month for calls. The error message is something about an unauthorised resource, as I recall, which a lot of googling tells me is a file permission error, perhaps, but Skype’s log contains zero information about the resource in question even though people have been experiencing the problem for a year or more.)

Alexander et al’s Architecture Patterns

Architecture, Patterns, Town Planning

Any book on patterns must include the obligatory Christopher Alexander discussion. In my case, it’s brief, for the following reason:

One side benefit of this project has been to see how “patterns” are being accepted by the development community. The attention on the Ajax Patterns has always been on the “Ajax” and not the “Patterns”. This is a good thing and a welcome change from the late ’90s, when you not only had to explain what a pattern is, but also justify its existence. “Ajax” itself is a kind of pattern, one whose popularity is further evidence for the power of “just a name”. For these reasons, I’ll keep this section brief.

It’s brief, but it’s still there. The original book’s worth looking at in order to “get” patterns and pattern languages (as is the companion work, “The Timeless Way of Building”). Here are the best online references:

If you know something about these, you might want to mention it on wikipedia, current info on A Pattern Language is wanting.

Alexander et al’s Architecture Patterns

Architecture, Patterns, Town Planning

Any book on patterns must include the obligatory Christopher Alexander discussion. In my case, it’s brief, for the following reason:

One side benefit of this project has been to see how “patterns” are being accepted by the development community. The attention on the Ajax Patterns has always been on the “Ajax” and not the “Patterns”. This is a good thing and a welcome change from the late ’90s, when you not only had to explain what a pattern is, but also justify its existence. “Ajax” itself is a kind of pattern, one whose popularity is further evidence for the power of “just a name”. For these reasons, I’ll keep this section brief.

It’s brief, but it’s still there. The original book’s worth looking at in order to “get” patterns and pattern languages (as is the companion work, “The Timeless Way of Building”). Here are the best online references:

If you know something about these, you might want to mention it on wikipedia, current info on A Pattern Language is wanting.