Eric picks up the right stick, and perhaps even the right end of it, when he begins puzzling through DigID by way of credit cards. They don’t compare perfectly, but I do think that credit cards, perhaps in conjunction with cell phones, represent the point d’appui, the site where leverage toward DigID can most readily bear fruit without arm-twisting or hand-wringing. (Thus I’m not surprised to see Nokia, American Express, Vodaphone, VISA, and MasterCard among the Liberty Alliance members.)
I’m not a Passport expert, and I’m suspicious of Microsoft (not an MSFT-hater; that’s wasted energy) — so I’m not the one to predict whether Passport will be the lever. Liberty Alliance, though I suspect the trustworthiness of some if its partners, seems like a better bet; a collaborative approach runs less risk of misbehavior by a monopolistic proprietor, and their support of PingID and the open Jabber protocol make an impressive show of good faith.
Hey, Eric — why not seed this enterprise with something really attractive, such as an intriguing online game? Offer anyone who wants an ID to play Norlin-Land, and then say, “You know, if you’d like to buy a book from Amazon, just enter your credit card number in your preferences dialogue box.” The game doesn’t have to be as intricate as Unreal Tournament or Ultima or Sims Online; in a certain sense, the simpler the better. (Although just imagine what would happen if the game were itself fascinating; think of the possibilities if Liberty Alliance were to make a partnership with Ludicorp for the Game NeverEnding. The mind reels . . . .)
Posted by AKMA at May 28, 2003 03:43 PM | TrackBackre: gaming & DigID...
it is probably not coincidence that the guys over at Msft's palladium/enscub project keep talking about online gaming....
Posted by: eric norlin at May 28, 2003 08:56 PMWhen the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.
Posted by: Josias at January 13, 2004 11:39 AMInside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.
Posted by: Ellen at January 13, 2004 11:41 AMTo address this issue, we turn to the second place to put variables, which is called the Heap. If you think of the Stack as a high-rise apartment building somewhere, variables as tenets and each level building atop the one before it, then the Heap is the suburban sprawl, every citizen finding a space for herself, each lot a different size and locations that can't be readily predictable. For all the simplicity offered by the Stack, the Heap seems positively chaotic, but the reality is that each just obeys its own rules.
Posted by: Quivier at January 13, 2004 11:41 AM