mail page 2 - Dave's Blog

Elaborating on a previous brief post on the topic of Web Worker initialization race conditions, there's two important points to avoid a race condition when setting up a Worker:

1. The parent starts the communication posting to the worker.
2. The worker sets up its message handler in its first synchronous block of execution.

For example the following has no race becaues the spec guarentees that messages posted to a worker during its first synchronous block of execution will be queued and handled after that block. So the worker gets a chance to setup its onmessage handler. No race:

'parent.js':
   var worker = new Worker();
   worker.postMessage("initialize");

'worker.js':
   onmessage = function(e) {
      // ...
   }

The following has a race because there's no guarentee that the parent's onmessage handler is setup before the worker executes postMessage. Race (violates 1):

'parent.js':
   var worker = new Worker();
   worker.onmessage = function(e) {
      // ...
   };

'worker.js':
   postMessage("initialize");

The following has a race because the worker has no onmessage handler set in its first synchronous execution block and so the parent's postMessage may be sent before the worker sets its onmessage handler. Race (violates 2):

'parent.js':
   var worker = new Worker();
   worker.postMessage("initialize");

'worker.js':
   setTimeout(
      function() {
         onmessage = function(e) {
            // ...
         }
      },
      0);

Most existing DRM attempts to only allow the user to access the DRM'ed content with particular applications or with particular credentials so that if the file is shared it won't be useful to others. A better solution is to encode any of the user's horrible secrets into unique versions of the DRM'ed content so that the user won't want to share it. Entangle the users and the content provider's secrets together in one document and accordingly their interests. I call this Blackmail DRM. For an implementation it is important to point out that the user's horrible secret doesn't need to be verified as accurate, but merely verified as believable.

Apparently I need to get these blog posts written faster because only recently I read about Social DRM which is a light weight version of my idea but with a misleading name. Instead of horrible secrets, they say they'll use personal information like the user's name in the DRM'ed content. More of my thoughts stolen and before I even had a chance to think of it first!

As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping). The basest ignorance is with respect to the mere existence of percent-encoding. Percents in URIs are special: they always represent the start of a percent-encoded octet. That is to say, a percent is always followed by two hex digits that represents a value between 0 and 255 and doesn't show up in a URI otherwise.

The IPv6 textual syntax for scoped addresses uses the '%' to delimit the zone ID from the rest of the address. When it came time to define how to represent scoped IPv6 addresses in URIs there were two camps: Folks who wanted to use the IPv6 format as is in the URI, and those who wanted to encode or replace the '%' with a different character. The resulting thread was more lively than what shows up on the IETF URI discussion mailing list. Ultimately we went with a percent-encoded '%' which means the percent maintains its special status and singular purpose.

I previously described my desire to hook my Outlook calendar up to my Google calendar. I just found out that I can do this and the reverse as both support publishing calendars to the Internet. The following are how I set this up under Outlook 2010 and Google Calendar:

In Outlook, I go to the calendar view, right click on my calendar and select "Share Publish to Office.com". At this point I can change the permissions to allow anonymous Internet access, and under Detail change between 'Full details' (full calendar), 'Limited details' (subject lines & availability only), 'Availability only'. Availability only is almost just what I want -- I'd also like to include location but availability only is good enough. After hitting OK here I get a 'Do you want to send an invitation...' dialog box. I hit 'Yes' and I can copy the webcals:// URL out of the email window that opens up. Next, to add it to my Google calendar, I open http://www.google.com/calendar/, and under 'Other calendars', I select 'Add Add by URL', paste in that webcals:// URL but change the 'webcals' at the start to 'https'.

In Google Calendar, I can click on my calendar name under 'My calendars', select 'Calendar settings', and on the new page, look under 'Calendar Address', click the ICAL icon, and copy the URL in the new dialog. Now back in Outlook I go to the Calendar view, right click on 'My Calendars', and select 'Add Calendar From Internet...'. In the new dialog that pops up I paste in the URL from Google Calendar.

In this fashion I can share public calendar data between my personal and work calendars.