Yes, I was paying attention during the download strategies talk, but
even Python eggs scare me, so I didn't write about it.
The way I'm teaching it, like to GIS people who gave me a slot on
Tuesday in Vancouver: picture a castle with a moat and a keep, like
in Shrek sort of, where the fortified keep represents the data store
(persistence layer, database, model, schema or schemaless), with
visualizations being developed as a kind of all around theater (view),
and with http request and response objects going in and out the main
gate (the moat reminds us to talk about security, ports 'n firewalls
and like that). It's just a mnemonic, a mental cartoon, helps map out
the concepts.
Being a Python guy, I make Python the controller in the above MVC
architecture, but then that's all server side thinking. Once you get
to the client, it's all about Javascript and the DOM, and providing a
quality user experience (thin client model -- if it's a thick client,
like a game, then that's another story).
The server might be far away and asynchronous, a seething pit of
Twisted snakes in Iceland for example (thinking of one of our flagship
user-companies). So of course you want those httpResponse suitcases
to contain plenty of Javascript, libraries and so on. That's all
happily dispensed to any who come knocking. Javascript is what makes
a browser come to life, animates it from within.
I teach for Saturday Academy sometimes, blog the lessons sometimes.
'Revolution OS' gets excerpted (yes it's dated, still has good info),
plus we show 'Warriors of the Net', a very well made cartoon about
tcp/ip.
Regarding last night's meeting: I don't encounter a lot of resistance
to using Mozilla where an application demands it, as Mozilla runs
great on Windows and doesn't interfere with IE. YMMV.
Kirby