Reflections

AsyncCalls and Internet Explorer / JavaScript

doug-walter — Fri, 28 Jul 2006 16:02:00 GMT

A friend of mine asked me recently if I knew of an elegant way to handle asynchronous calls in Internet Explorer. Basically the problem starts with some event like “load a page” then “do something” after the page is done loading. With the emergence of AJAX-style applications which exploit this asynchronous behavior quite heavily, it's interesting to have some way to write code that handles async calls. This is especially true if you want to write automated test scripts.

In any case, I sat down this morning and wrote up the following. It's only the solution. I'll let you work out how to integrate it in with a real problem:

function AsyncCall(action, condition, callback, timeout) {
action();
window.setTimeout("onTimer(" + condition + ", " + callback + ", " + timeout + ")", timeout);
}

function onTimer(condition, callback, timeout) {
if (condition()) {
callback();
}
else {
window.setTimeout("onTimer(" + condition + ", " + callback + ")", timeout);
}
}

You would then introduce a call like:

AsyncCall(setUrl, checkFrame, notifyDone, 100);

This invokes the “action“ function, then periodically checks the “condition“ function. When the condition returns true, then it calls the “callback“ function.

Here's a simple web page that lets you set the SRC property of an IFrame, then notifies you when the page is completely loaded:

<html>
<head>
<title>Async Test</title>
</head>
<script language="JScript" src="asynccall.js"></script>
<script language="JScript">
function updatePage() {
AsyncCall(setUrl, checkFrame, notifyDone, 100);
}
function setUrl() {
document.all["myFrame"].src=myForm.url.value;
}
function checkFrame() {
return document.all["myFrame"].readyState == "complete";
}
function notifyDone() {
alert("Done!");
}
</script>
<body>
<form id="myForm">
<input type="text" name="url" />
<input type="button" value="Go" onClick="updatePage()" />
</form>
<iframe id="myFrame" src="about:blank" height="100%" width="100%"></iframe>
</body>

Happy async calling!

-Doug

Application Identity

doug-walter — Wed, 14 Dec 2005 04:36:00 GMT

There’s this fantasy that applications will someday be able to identify themselves. That is, they will be able to act as a “principal”, just like you or me. This doesn't make sense.

In reality, applications are agents; agents of a real user. That is, applications (aka. code) acts because a user told it to. If this was not universally true, then someone has figured out true AI (artificial intelligence) and the landscape of computer systems as we know it is forever changed. I’ve been watching the 5 O’clock news. There haven’t been any major breakthroughs in AI lately. Until that day, software is simply an agent of a user, period.

Some people think that if only you could identify the app, then you cold hold the app-writer accountable and therefore hold harmless the user who unwittingly invoked the app.

But wait a second, how dumb could a crook be to let you know who he is? Let’s say he writes this awesome worm that completely messes with everything in your system. Is he going to sign the app as “Crook”? Is he going to place a return address on his app? “Here, I’m at 1111 Stupid Lane, come and get me!” Absolutely not! Hackers have always focused on those vulnerabilities which leave no trace back to them. That’s just common sense.

Let’s say you’re a good company, conscientious in every way. What’s the first thing you’re going to place on your license agreement? I’m no lawyer, but I expect it will read something like “XXX corporation is not responsible for any damages the user might encounter while using this software…” etc. etc. etc.

Now back to application IDs. I’m not saying that signing software isn’t a good idea. On the contrary! More and more applications are being delivered online. Signing the application manifest including a digest of all binaries is just common sense. But remember the disclaimer. The signatures are just there to enable you to 1) make an informed decision about whether the package you got came from who you thought it did and 2) that any attempt to modify the application in transit can and will be detected. You can also use the manifest to ensure that the application remains unchanged over time.

What I object to is the notion that an application can act on its own. I object to the notion that an app can authenticate to a remote party. This makes no sense. On the other hand, if the user (eg. person) wants to cough up the manifest associated with the application he’s running, that’s certainly his prerogative. In fact, a relying party may require this. However, the trust, the liability, the responsibility is on the user to ensure that A) his system is functioning within parameters, B) the application he’s running is the one he wants and C) the actions taken on his behalf by the application are ultimately his responsibility.

Won’t this mean that users will be held accountable for stuff they have no control over? No. They can always choose not to run a piece of software, not to use a computer, or to use a different operating system. In fact, because software runs under the context of the user and the user most likely has the potential to do whatever it wants with the software, this actually creates a completely new problem. What’s to prevent a malicious user from intentionally modifying the software in such a way as to damage the reputation of the software publisher, or even to hold the software publisher accountable for actions taken with that software?

In short, applications are not principals. They do not act on their own. Software publishers are not responsible for the actions taken by a user. Users must always be held accountable for the actions they take, no matter the agent. Let’s make operating systems and software that enable users to make informed decisions about which agents to invoke, and allow them to control the rights and privileges afforded to the agent. This makes sense.

PDC2005 - COM214 - What happened?

doug-walter — Thu, 29 Sep 2005 18:28:00 GMT

If you attended John Shewchuck's talk COM214 - you probably remember all sorts of things going wrong with my demo. I know this is going to sound largely apologetic, but my real intent is to highlight what not to do with a demo in front of a whole bunch of people.

Here's what I learned:

1. Don't run on beta versions of the OS unless you have to!

2. Split screen demos just don't work! Craning my neck to see what the audience was seeing, pop-up dialogs appearing on the wrong screen, and finding the mouse pointer made it all but impossible to show what was going on.

3. Have a backup machine that's booted, and ready to resume your demo!

4. If your demo involves writing code, keep snapshots of all key points along the way! See #3.

5. Tech check all machines you might use, backups included!

6. Don't share demo machines! It's tempting, especially if it's a 64-bit Ferrari; nonetheless, resist!

7. Show less, not more!

I want to thank Nigel Watling who, in a moment of brilliance and forethought, reminded me that InfoCard would only draw on the primary screen of the demo machine. Had I continued running on the backup machine, along with its split screen configuration, the InfoCard part of the demo would have been a complete flop! Imagine, me holding a laptop high over my head, and pointing “See, isn't it beautiful”?

Anyways, lessons learned...

PDC 2005 - COM430 Demos posted

doug-walter — Thu, 29 Sep 2005 16:42:00 GMT

It's taken a while, but it's finally there.

http://commnet.microsoftpdc.com/downloads.aspx

Look for COM430.zip