-
comedy. high comedy.
-
"I can completely relate to what Stephen is asking for. It's far simpler than the problems a persistence technology like Google (NSDQ: GOOG) Gears is trying to tackle. But ultimately, thanks in part to Gears and similar technologies from Adobe (NSDQ: ADBE), Apache, Oracle, and Sun, we know more is possible. So, why accept less?" – because it's likely to arrive far more quickly 😉
-
likely to be the only political link you see from me this election: i recommend you read this, if only because it's not (at all) what you think it is. perhaps the most compelling statement i've seen this election, with the possible exception of Powell's endorsement.
-
"The reason has always been that I don't like single-issue people, nor do I think that people who turn the world into black and white are very nice or ultimately very useful. The fact is, there aren't just two sides to any issue, there's almost always a range or responses, and "it depends" is almost always the right answer in any big question. And not being even willing to see the other side makes for bad decisions." – agreed on pretty much all counts
tecosystems
links for 2008-11-03
Share via Twitter Share via Facebook Share via Linkedin Share via Reddit
BillSaysThis says:
November 3, 2008 at 11:15 pm
Thanks for the Esquire link–it sums up my feelings very well and with eloquence.
David Berlind says:
November 5, 2008 at 8:20 am
Regarding your answer “because it’s likely to arrive far more quickly”, is that really true? In this case, the science of caching form data in a way that’s recoverable during some future session is nearly as difficult as solving the persistence problem in general. A modicum of structure would be required and, as you know, the majority of form-based HTML pages lack structure.
With such a lack of structure to these pages, the only approach might be something like a plug-in that’s the equivalent of an autosave (like what Gmail does), but instead, to the local hard drive where it can be retrieved. But I suspect that even that is almost as complicated as the persistence problem.
For example, go to any page with a form on it (even the one to fill out a comment on your blog), fill some of the form out, and then hit File Save and save the file to your local hard drive. Now, open that file with file open and you’ll notice that whatever you filled into the form is no longer there.
State in combination with lack of structure (even though the form seems structured) is most definitely an issue. The more I think it through, the more I realize how it’s really a thorny problem.
Thread-per-tab browsers (like Chrome) might be a part of the answer in that each tab could run in its own shell and those shells in turn could be capable of running some code against the currently loaded page in a way that doesn’t interfere with the HTTP server’s understanding of the page’s state. I’m thinking “screen scraping” tech that independently (of the web server) creates its own last known state for every tab.
One question if this were working…: would ordinary users expect the cached-page to be able inject the recovered information into the “real pages” when they’re available? You’re a power user. The idea that you might be able to pull the cached page back and copy & paste some information somewhere so it doesn’t get lost isn’t exactly a great user experience. Most people would get to that recovered page and ask “Now what?.” There would be an expectation that the recovered page could inject the data back into the real page (when it’s available), in which case, a significant amount of flexible structure and intelligence would have to be incorporated into the solution…. an architecture that’s remarkably close to being a persistence mechanism.