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

0:00

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
    logic.]
  - With JSP etc, can still let a web designer work on the
    template
    [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 AjaxPatterns.org 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?

SAG Ajax Patterns Review 1 – XHR Call, IFrame Call, HTTP Streaming

A little while back, I mentioned that some people in the patterns community have been noticing the Ajax Patterns. In particular, there have been a series of discussions about the patterns by the Software Architecture Group in the University of Illinois Computer Science Dept (home of Netscape forerunner Mosaic btw). The SAG is led by Ralph Johnson (Gang Of Four “Design Patterns” author) and the group also includes Brian Foote, who blogged about Ajax as a pattern earlier on and has kindly been keeping me updated on the MP3s emerging from these discussions.

The feedback has been very helpful and I’ve been able to incorporate it in time for the physical publication – thanks again to everyone in the group.

While listening to the audio, I’ve been taking notes and writing some comments. With the permission of Ralph and Brian, I’m going to be posting these, each discussion as a separate post. It’s an opportunity to see how a group of very intelligent people without much Ajax experience respond to Ajax and the Ajax patterns. You’ll notice two conventions here: “TODO” is a note to myself that some action needs to be taken. “MM” signals my ideas, views, and comments back to the group.

Jan-30-2006 First Ajax Patterns Discussion

30/1/2006 Ajax Workshop

9:45 XMLHttpRequest Call

What it's about. - Probably missing in old browsers if you can't use Ajax on them. - Remote call to server without refreshing a whole page. - I assumed in JS you can open a socket, you could have done this yourself. - Depends on what the browser provides. But not cross-browser. [TODO Mention HTTP restriction and what JS can do, cf Richer Plugin] - Ironically, because JS isn't general-purpose (due to security), it's wound up being a better citizen. Also because it was kind of low-brow, everyone kind of ignored it. - The big idea is this is a way to call the server.

Interesting characteristic of XHR: - Asynchronous - Built-in security (originating server)

Did you find this pattern easy to understand? - One thing that troubles me (not particular to this pattern), pretty soon the code becomes spaghetti-like. Nd good patterns on how to manage code. [MM Agree, we need a JS patterns book! That's not the aim here, the book will make that explicit]. - Part of the problem here is JS itself. - Haven't seen the word "simple" "elegant" or "pretty" to describe JS architect. This is a Rube Goldberg solution, duct-tape ... at it's best. [MM Sort of true, but there's a lot that can be done to improve it] - There are libraries that help. (AjaxCaller, Prototype).

Writing here, even though it doesn't address these problems, could understand/follow it? - I don't like the Problems section. "How can the browser communicate with the server?" But this pattern is more specific than server communication. The next 1-2 patterns have the same problem. - But the problem might be the same, but different Solution. What I dislike is the forces are also the same. How does it mitigate the forces? Maybe there should be some different forces. - Only difference between IFrame and XHR is only restricted to same host, so maybe okay other than that. [MM Actually, even this difference doesn't exist, since you can't read a remote IFrame's content] [TODO Possibly update forces to be different, back-reflect the solution]

22:30 Doesn't say anything about being asynchronous at the start - Ajax should be highly responsive. Distributed system, so you want to minimise communications. ie Must be asynchronous [TODO Revise forces. HOWEVER, note that XHR doesn't have to be async.] - "Conventional means ... slow." He's trying to rule out Solutions, before we get to the solution. [MM This sort of goes against the previous suggestion that IFrame and XHR need different Forces. Maybe suggests different people have different views on this issue of the forces.] Doesn't so much talk about the forces as take potshots at existing solutions. [MM This is a fair point, more prevalent in the initial patterns as they're arising as a reaction to conventional web dev, but it's true you don't have to formulate them that way.]

26:30 It's a long pattern, is that okay? - Yes, longer than all the others, problem if all patterns were this long, but given it's so core to Ajax, it's fine. - Length is fine, but a lot of code there. - I would like more examples of the old way of doing things. [Covered in the Anagrams tutorial, perhaps reference it] - The general idea is if you have a big object and only small things change at a time, then you keep going back to the server and grabbing small bits of it. I think of Google Maps. - Pattern could be shorter if PHP wasn't written. - So you'd like less example code, others want more. - It's a Chimera/Frankenstein ie PHP (or whatever serverside) on the one side, and even JS is a kind of Frankenstein language. So it's important to have the PHP, reminds me that's the game I'm playing. I didn't mind it, seeing all the pieces together reminds you we're receiving small chunks etc. - The pattern is really introducing XHR, not how to use it. - Disagree with people who are trying to call everything a pattern. - Well, these particular patterns are what he calls foundational. He says they're not really patterns, they're just how the technology works. - I know what you're saying about that, and it bugs me too, but I've been trying to come up with a rationalisation for admitting that this kind of design exposition is a contribution to our software architecture literature ... and if designs recur, if a lot of people come up with the same solution to a problem ... my mind cries out to keep distinct from Visitor and ... Composite, but I don't have the vocab to keep them distinct, and I want to maintain this notion that the patterns community is talking about good ideas that keep coming up over and over that we haven't come up with ourselves ... true, it's a different kind of discussion from the GoF, without having disclaimer kind of nags at me [MM Agree wholeheartedly, why I've sounded a bit apologetic describing these as patterns, but they just fit into the overall language well. See earlier blog post.] [TODO Needs better "disclaimer" in the book] - So then what are the patterns around XHR? - Event handling, Asynchronous call - Lots of people dealing with SOA, problems s.a. async smell the same but with different names [MM Later patterns, e.g. Distr'd events] - Error detection - Invesion-of-control/DepInj/Observers. People patternising closures. There's an aspect of dealing with callbacks. Callbacks are part of the discussion here, and that's an idea that comes up here. - Feedback from the call. Or using poll. Fire-and-forget. Typical remote invocation styles: What does XHR do? - In JS: Callbacks used here (XHR), also used for user interops. We want to follow flow-of-control, but if everything is event handlers, hard to follow. (ie JS hard to follow because of this style.) A lot of the time, "callbacks" are basically continuations. It's a general pattern discussion we could have.

41:30 Real-World Examples and Code. - These systems are not thoroughly responsive as claimed. Google Suggest surprisingly fast. Others like Backpackit and Kiko not. [MM See perf optimisation, also comments in HTML Message, etc. Alex Kirk mentioned Kiko a while ago as a problem due to too much browser-side rendering.] - Need to avoid too many requests - Curious didn't mention the most famous examples (Google Suggest etc) Maybe can't see the code. But it's JS, have to be able to. But maybe unclear. [MM Yes, obfuscated. Also, tried to avoid the cliche references too much, they're mentioned elsewhere] - Discussion about mint stats package, security issues in uploading data. - Next, ways of telling your web browser what to report back. - If trying to keep people from attacking you. It's interesting to me. - Applets got crucified for some of the security problems that JS has. People moved on from panicking about them, but got away with it because browser wars finished etc.

=============================================================== 49:00 IFrame Call - Poor Man's version of the previous one. - More like a hack - What can you do with one that you can't do with the other? XHR and not with IFr? - I only know the other way round...IFrame is more compat with older browsers. - Long discussion about relative benefits etc. - Comment about Google using IFrame. Not sure if it's true as you can zoom in.[TODO More specific about how it's being used. (I think book version already does that)] - IFrame Call doesn't talk about hidden frames. [MM XHR Pattern alternatives has a detailed comparison)] [TODO XHR comparison should briefly explain how the two are diff, not just compare the benefits] - IFrame has no timeout function. (But could fake this using polling) - Calls IFrame a hack ... Pot calling the kettle black, since Ajax itself is sort of a hack. Is it bad just because it's old? [MM Again, comes down to the comparison. XHR is a more intention-based, intuitive, API, although it's true that you won't care about that because you should use a wrapper lib anyway. Better argument is the extra functionality such as call tracking.] - Would like better explanation on what's so bad about IFrames. [TODO Include x-reference in IFrame Solution. Also mention the portable wrappers in the Solution, ie you shouldn't actually care/know which you're using is the more pertinent issue here.] - I'm feeling historical. The room we used to sit in is the room where the original Mosaic web browser developers sat. Continuously astonished in the web industry, using things that in ways they weren't invented for. Go down this list, frames, tables ... Ungodly mess, but really impressed, poster child for pragmatism and "worse is better". IFrame is a typical example. - I didn't get any feel on whether I would use one or the other. - Intrigued by the history of JS. Knowing that IFrame predated XHR because features that made it easier to do the second came along in 2003. Whether it needs to be here, not sure. [TODO Sidebar?]

=============================================================== 49:00 HTTP Streaming

Is it competition for the other two?  
  - Different problem (push/streaming)
  - "How can the browser communicate with the server?" Same
    problem as the other two.
    - I don't know, it turns the table. Little pattern device
      of using the same problem with different solutions may
      be okay here. Here, the forces would be different.
      Could make the case for having the same problem.  [TODO
      Change the problem statement, just enough to make it a
      little different from previous two.]

What would make you choose this over the others?
  - Changes coming from lots of other sources, not just the
    client.
  - e.g. Chat system.
  - I don't want to do this. Don't want to grow the system
    ...
    - But scaleability is oversold. You'll never be like
      EBay, don't need to scale up like that.  [TODO Good
      point, mention in the pattern.]
    - Our wiki - 4-5 hits per second - can handle that, but
      not scaleable.  Wikipedia is not a wiki in that sense,
      pages don't change because I believe something like 90%
      of all edits are done by 200 people, these are official
      wikipedia authors. Specific process.
    - Doesn't fit into proxies. Caching etc doesn't ddeal
      with longer responses.

Long refactoring illustration here. Do the others have one?
  - Streaming wiki demo.
  - Seemed nice to refactor in this way.
  - The group is looking at the live version on the web -
    "There's about a half dozen laptops in it for the
    author's information". It worked.  [MM Phew]

=============================================================== 1:20 - I didn't get the feel of which one to use. - Was hidden in the Alternatives section [MM TODO Emphasise this in the partintro, maybe in the solutions]

====== Next time: Different patterns - Problem with web version [MM Incidentally, the wiki publishing hasn't worked out ideally, didn't get the full benefit as I didn't open up the wiki (and still haven't due to spam). Ideally would have better PS format. (Blogged about printing from the web a yr ago as it happens.)] - Being on the web doesn't seem to affect (ie drop) sales. [MM We'll soon find out...:-)]

SAG Ajax Patterns Review 1 – XHR Call, IFrame Call, HTTP Streaming

A little while back, I mentioned that some people in the patterns community have been noticing the Ajax Patterns. In particular, there have been a series of discussions about the patterns by the Software Architecture Group in the University of Illinois Computer Science Dept (home of Netscape forerunner Mosaic btw). The SAG is led by Ralph Johnson (Gang Of Four “Design Patterns” author) and the group also includes Brian Foote, who blogged about Ajax as a pattern earlier on and has kindly been keeping me updated on the MP3s emerging from these discussions.

The feedback has been very helpful and I’ve been able to incorporate it in time for the physical publication – thanks again to everyone in the group.

While listening to the audio, I’ve been taking notes and writing some comments. With the permission of Ralph and Brian, I’m going to be posting these, each discussion as a separate post. It’s an opportunity to see how a group of very intelligent people without much Ajax experience respond to Ajax and the Ajax patterns. You’ll notice two conventions here: “TODO” is a note to myself that some action needs to be taken. “MM” signals my ideas, views, and comments back to the group.

Jan-30-2006 First Ajax Patterns Discussion

30/1/2006 Ajax Workshop

9:45 XMLHttpRequest Call

What it's about. - Probably missing in old browsers if you can't use Ajax on them. - Remote call to server without refreshing a whole page. - I assumed in JS you can open a socket, you could have done this yourself. - Depends on what the browser provides. But not cross-browser. [TODO Mention HTTP restriction and what JS can do, cf Richer Plugin] - Ironically, because JS isn't general-purpose (due to security), it's wound up being a better citizen. Also because it was kind of low-brow, everyone kind of ignored it. - The big idea is this is a way to call the server.

Interesting characteristic of XHR: - Asynchronous - Built-in security (originating server)

Did you find this pattern easy to understand? - One thing that troubles me (not particular to this pattern), pretty soon the code becomes spaghetti-like. Nd good patterns on how to manage code. [MM Agree, we need a JS patterns book! That's not the aim here, the book will make that explicit]. - Part of the problem here is JS itself. - Haven't seen the word "simple" "elegant" or "pretty" to describe JS architect. This is a Rube Goldberg solution, duct-tape ... at it's best. [MM Sort of true, but there's a lot that can be done to improve it] - There are libraries that help. (AjaxCaller, Prototype).

Writing here, even though it doesn't address these problems, could understand/follow it? - I don't like the Problems section. "How can the browser communicate with the server?" But this pattern is more specific than server communication. The next 1-2 patterns have the same problem. - But the problem might be the same, but different Solution. What I dislike is the forces are also the same. How does it mitigate the forces? Maybe there should be some different forces. - Only difference between IFrame and XHR is only restricted to same host, so maybe okay other than that. [MM Actually, even this difference doesn't exist, since you can't read a remote IFrame's content] [TODO Possibly update forces to be different, back-reflect the solution]

22:30 Doesn't say anything about being asynchronous at the start - Ajax should be highly responsive. Distributed system, so you want to minimise communications. ie Must be asynchronous [TODO Revise forces. HOWEVER, note that XHR doesn't have to be async.] - "Conventional means ... slow." He's trying to rule out Solutions, before we get to the solution. [MM This sort of goes against the previous suggestion that IFrame and XHR need different Forces. Maybe suggests different people have different views on this issue of the forces.] Doesn't so much talk about the forces as take potshots at existing solutions. [MM This is a fair point, more prevalent in the initial patterns as they're arising as a reaction to conventional web dev, but it's true you don't have to formulate them that way.]

26:30 It's a long pattern, is that okay? - Yes, longer than all the others, problem if all patterns were this long, but given it's so core to Ajax, it's fine. - Length is fine, but a lot of code there. - I would like more examples of the old way of doing things. [Covered in the Anagrams tutorial, perhaps reference it] - The general idea is if you have a big object and only small things change at a time, then you keep going back to the server and grabbing small bits of it. I think of Google Maps. - Pattern could be shorter if PHP wasn't written. - So you'd like less example code, others want more. - It's a Chimera/Frankenstein ie PHP (or whatever serverside) on the one side, and even JS is a kind of Frankenstein language. So it's important to have the PHP, reminds me that's the game I'm playing. I didn't mind it, seeing all the pieces together reminds you we're receiving small chunks etc. - The pattern is really introducing XHR, not how to use it. - Disagree with people who are trying to call everything a pattern. - Well, these particular patterns are what he calls foundational. He says they're not really patterns, they're just how the technology works. - I know what you're saying about that, and it bugs me too, but I've been trying to come up with a rationalisation for admitting that this kind of design exposition is a contribution to our software architecture literature ... and if designs recur, if a lot of people come up with the same solution to a problem ... my mind cries out to keep distinct from Visitor and ... Composite, but I don't have the vocab to keep them distinct, and I want to maintain this notion that the patterns community is talking about good ideas that keep coming up over and over that we haven't come up with ourselves ... true, it's a different kind of discussion from the GoF, without having disclaimer kind of nags at me [MM Agree wholeheartedly, why I've sounded a bit apologetic describing these as patterns, but they just fit into the overall language well. See earlier blog post.] [TODO Needs better "disclaimer" in the book] - So then what are the patterns around XHR? - Event handling, Asynchronous call - Lots of people dealing with SOA, problems s.a. async smell the same but with different names [MM Later patterns, e.g. Distr'd events] - Error detection - Invesion-of-control/DepInj/Observers. People patternising closures. There's an aspect of dealing with callbacks. Callbacks are part of the discussion here, and that's an idea that comes up here. - Feedback from the call. Or using poll. Fire-and-forget. Typical remote invocation styles: What does XHR do? - In JS: Callbacks used here (XHR), also used for user interops. We want to follow flow-of-control, but if everything is event handlers, hard to follow. (ie JS hard to follow because of this style.) A lot of the time, "callbacks" are basically continuations. It's a general pattern discussion we could have.

41:30 Real-World Examples and Code. - These systems are not thoroughly responsive as claimed. Google Suggest surprisingly fast. Others like Backpackit and Kiko not. [MM See perf optimisation, also comments in HTML Message, etc. Alex Kirk mentioned Kiko a while ago as a problem due to too much browser-side rendering.] - Need to avoid too many requests - Curious didn't mention the most famous examples (Google Suggest etc) Maybe can't see the code. But it's JS, have to be able to. But maybe unclear. [MM Yes, obfuscated. Also, tried to avoid the cliche references too much, they're mentioned elsewhere] - Discussion about mint stats package, security issues in uploading data. - Next, ways of telling your web browser what to report back. - If trying to keep people from attacking you. It's interesting to me. - Applets got crucified for some of the security problems that JS has. People moved on from panicking about them, but got away with it because browser wars finished etc.

=============================================================== 49:00 IFrame Call - Poor Man's version of the previous one. - More like a hack - What can you do with one that you can't do with the other? XHR and not with IFr? - I only know the other way round...IFrame is more compat with older browsers. - Long discussion about relative benefits etc. - Comment about Google using IFrame. Not sure if it's true as you can zoom in.[TODO More specific about how it's being used. (I think book version already does that)] - IFrame Call doesn't talk about hidden frames. [MM XHR Pattern alternatives has a detailed comparison)] [TODO XHR comparison should briefly explain how the two are diff, not just compare the benefits] - IFrame has no timeout function. (But could fake this using polling) - Calls IFrame a hack ... Pot calling the kettle black, since Ajax itself is sort of a hack. Is it bad just because it's old? [MM Again, comes down to the comparison. XHR is a more intention-based, intuitive, API, although it's true that you won't care about that because you should use a wrapper lib anyway. Better argument is the extra functionality such as call tracking.] - Would like better explanation on what's so bad about IFrames. [TODO Include x-reference in IFrame Solution. Also mention the portable wrappers in the Solution, ie you shouldn't actually care/know which you're using is the more pertinent issue here.] - I'm feeling historical. The room we used to sit in is the room where the original Mosaic web browser developers sat. Continuously astonished in the web industry, using things that in ways they weren't invented for. Go down this list, frames, tables ... Ungodly mess, but really impressed, poster child for pragmatism and "worse is better". IFrame is a typical example. - I didn't get any feel on whether I would use one or the other. - Intrigued by the history of JS. Knowing that IFrame predated XHR because features that made it easier to do the second came along in 2003. Whether it needs to be here, not sure. [TODO Sidebar?]

=============================================================== 49:00 HTTP Streaming

Is it competition for the other two?  
  - Different problem (push/streaming)
  - "How can the browser communicate with the server?" Same
    problem as the other two.
    - I don't know, it turns the table. Little pattern device
      of using the same problem with different solutions may
      be okay here. Here, the forces would be different.
      Could make the case for having the same problem.  [TODO
      Change the problem statement, just enough to make it a
      little different from previous two.]

What would make you choose this over the others?
  - Changes coming from lots of other sources, not just the
    client.
  - e.g. Chat system.
  - I don't want to do this. Don't want to grow the system
    ...
    - But scaleability is oversold. You'll never be like
      EBay, don't need to scale up like that.  [TODO Good
      point, mention in the pattern.]
    - Our wiki - 4-5 hits per second - can handle that, but
      not scaleable.  Wikipedia is not a wiki in that sense,
      pages don't change because I believe something like 90%
      of all edits are done by 200 people, these are official
      wikipedia authors. Specific process.
    - Doesn't fit into proxies. Caching etc doesn't ddeal
      with longer responses.

Long refactoring illustration here. Do the others have one?
  - Streaming wiki demo.
  - Seemed nice to refactor in this way.
  - The group is looking at the live version on the web -
    "There's about a half dozen laptops in it for the
    author's information". It worked.  [MM Phew]

=============================================================== 1:20 - I didn't get the feel of which one to use. - Was hidden in the Alternatives section [MM TODO Emphasise this in the partintro, maybe in the solutions]

====== Next time: Different patterns - Problem with web version [MM Incidentally, the wiki publishing hasn't worked out ideally, didn't get the full benefit as I didn't open up the wiki (and still haven't due to spam). Ideally would have better PS format. (Blogged about printing from the web a yr ago as it happens.)] - Being on the web doesn't seem to affect (ie drop) sales. [MM We'll soon find out...:-)]