On why I'm skeptical about the "permanently connected" stuff
I've blogged many times about my skeptical attitude about service models based on the "permanently connected" paradigm. Let me tell you this funny (more or less) anecdote that happened to me this morning. Not to be taken too seriously.
Today I'm teaching a class for Sun in the Milan hinterland. When I got off my car in the park lot, I've accidentally dropped the car keys into a street drain (a perfect hit into the only drain in 100 m^2). Of course I've got a backup of the keys, but they are at the moment in my house in Genoa.
But don't worry. I supposed I could call a courier and have my parents to send me the backup keys - organizing the thing early in the morning should be ok for getting the delivery within 5PM. So I phoned the courier, asked for information (to make sure the delivery can be actually made within 5PM, or I'd loose the backup keys too!) and organize the delivery. In spite of being in the middle of a highly populated area, the quality of the mobile signal was low. In a few words, after ten minutes of giving the details of the delivery, the line dropped. Puff. Of course, if I call again the courier I won't get in touch with the same operator (this is the problem of stateless Session Bean, I presume, so you could also interpret this story as a rant against stateless models, at least from the user's perspective), so I would have to restart from scratch. But I'm teaching a class and I can't have my students on hold for too long.
So I gave up and this evening, when the class ends, I'll try to find another solution. So, don't feel safe about that "permanently connected" stuff. Sometimes the network doesn't work. Well, at least today it's not raining.
PS If you are wandering on why I'm not using the web pages of the courier to set up the delivery, it's because I wanted to have a *direct* confimation that the delivery would be completed in time.