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...:-)]
