Key Web App Standard Approaches Consensus 143
suraj.sun tips a report up at CNet which begins:
"Browser makers, grappling with outmoded technology and a vision to rebuild the Web as a foundation for applications, have begun converging on a seemingly basic but very important element of cloud computing. That ability is called local storage, and the new mechanism is called Indexed DB. Indexed DB, proposed by Oracle and initially called WebSimpleDB, is largely just a prototype at this stage, not something Web programmers can use yet. But already it's won endorsements from Microsoft, Mozilla, and Google, and together, Internet Explorer, Firefox, and Chrome account for more than 90 percent of the usage on the Net today. 'Indexed DB is interesting to both Firefox and Microsoft, so if we get to the point where we prototype it and want to ship it, it will have very wide availability,' said Chris Blizzard, director of evangelism for Mozilla. ... Microsoft publicly endorsed Indexed DB on its IE blog: 'Together with Mozilla, we're excited about a new design for local storage called Indexed DB. We think this is a great solution for the Web,' said program manager Adrian Bateman."
Golden age of the web set to continue (Score:3, Informative)
Personally the new web technology that I'm most keen to get my hands on is the pushState/replaceState [mozilla.org] stuff that is going to be in the next release of Firefox after 3.6. It makes it much easier to deal with forward/back in AJAX web apps
More on topic, it is good to see Microsoft looking to implement new web technologies again.... if they implement much of HTML5 and they seem to be doing that now and this new Indexed DB stuff it looks like the Golden Age of the web will continue for some time.
Re:Golden age of the web set to continue (Score:4, Insightful)
> ...it looks like the Golden Age of the web will continue...
Provided that your definition of a Golden Age includes many new and exciting exploits.
Re: (Score:2)
> ...it looks like the Golden Age of the web will continue...
Provided that your definition of a Golden Age includes many new and exciting exploits.
The web isn't just for the enjoyment of users. Developers need to get their fix of fun, too.
Re: (Score:3, Interesting)
Exploits is the one of the many issues. How about change control, patching and schema changes, this has got catastrophe written all over it unless the API accounts for a lot more than whats written any serious database application reliant on it would require a strong set of change log rules, shifting data when needed, schema compliance checks before allowing access.
Re:Golden age of the web set to continue (Score:4, Funny)
Don't look now, but someone used one of those exploits to replace your comment's font.
Re: (Score:1)
Re: (Score:2)
Don't look now ...
Why the heck not? How else is someone supposed to see a hacked *font*?
Re: (Score:2, Interesting)
it looks like the Golden Age of the web will continue for some time.
Dude, the web didn't even exist until about 18 years ago. We're still evaluating the impact that the internet is having on culture -- what with some countries defining it as an inalienable human right and others eager to all but destroy or censor the crap out of it, the "golden age" is not what I'd call this time period. I'd call it the friggin' dark ages -- a mish-mash of global entities all competing at cross-purposes, a thriving black market, and every week more of our technology becomes connected to it,
Re: (Score:3, Interesting)
Re: (Score:2)
I like to think it's the phase where you've built a global government, but haven't built your UFO yet.
Re: (Score:2)
You win. Great comment - thanks.
Re:Golden age of the web set to continue (Score:5, Insightful)
I read that pushState / replaceState link and it scared me. Note the following from it:
Suppose http://mozilla.org/foo.html [mozilla.org] executes the following JavaScript:
var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");
This will cause the URL bar to display http://mozilla.org/bar.html [mozilla.org], but won't cause the browser to load bar.html or even check that bar.html exists.
Why do I have a feeling that said effect can and will primarily be used for horribly evil purposes?
Re: (Score:2)
Sounds OK to me as long as the site portion remains the same. This isn't any different from other cross-site scripting or impersonation problems. For all I care sites can do whatever they want to the URL bar as long as the site-identificating portion remains constant.
Re: (Score:2)
Fine for you, but what about the millions who will be reassured by the url displayed and end up handing their banking credentials over? The url display is supposed to display the current url and has been that way since the very beginning. Suddenly redefining it to display whatever the server wants is a terrible idea and a fraud waiting to happen.
Re: (Score:2)
What part of as long as the site portion remains the same did you miss? All you'll be able to change is the path portion within your site, which you already control anyway.
Ever since AJAX and DHTML, sites have had full control over what pages actually display, regardless of the URL they were accessed through. Websites can already manipulate the URL bar at will through javascript, it's jus
Re: (Score:2)
I don't think this would be a problem. If you already own the website, then you already can change the URL at will to anything you want.
The only reason this would be a bigger issue is XSS attacks - but those are already have way more important concerns than just spoofing the URL.
Personally, I would love it. It would make it much easier to merge the mobile/AJAX/static structures of the website, allow end-users to access the same bookmarks from multiple devices, and provide a much cleaner look than we alrea
Re: (Score:2)
Currently, the real issue with AJAX-webapp links is that the server never gets the hash (fragment) portion of the URL. This makes it hard to serve the correct page to a mobile device, and completely impossible if the device does not support JavaScript.
It also makes the server-side logs less and less useful, without introducing other kludges like calling "fake" URLs (via iframes or other tags) just to populate actual activity in the logs..
Re: (Score:2)
Server logs are logs of server activity. If no server activity is generated for certain user actions, why do you need logs? There's no fundamental difference between logs of user-visible URIs and logs of backend AJAX calls; in fact, AJAX API URIs can be made just as descriptive for server log purposes.
If you want to track user actions, then obviously you'll have to add an explicit tracking bug, which negates some of the advantages of dynamic sites without necessarily triggering server activity for each user
Re: (Score:2)
Server logs are logs of server activity.
you completely misunderstood my post. the point is that most platforms (gmail, for example) have moved to putting everything that would have typically lived in the query string behind a hash (#) because it's accessible in javascript. this stuff doesn't get sent to the server, of course, so doesn't show in logs.
Piled Higher and Deeper (Score:1)
Re: (Score:3, Funny)
Just a little more duct tape will fix it. No need for a clean state redesign. With enough kludging, ever increasing performance of local clients and Internet connections, we'll make it work and look just like a local app did ten years ago. Some day.
- T. Roll
Re:Piled Higher and Deeper (Score:5, Funny)
> ...look just like a local app did ten years ago.
No, no, no. It will look completely different. It'll have rounded corners. Or something. I know! It'll have animated 3D shadows! How can anyone get any work done using a program that lacks animated 3D shadows?
Re: (Score:2)
i *especially* am amazed at the Mac's throbbing shadows when your program opens several dozen windows. The first few windows only deepen the shadow, which is reasonable even if a waste of effort. But at some point, it decides that deepening the shadow would make it too big, so the shadow starts throbbing instead. I haven't tried writing a custom program to open windows at various speeds to see what happens, but I suspect it is not actually decreasing the shadow for each window, rather setting an internal
Re: (Score:2)
If there's any good side in it, it means you don't have to install some random untrusted applications on your computer but they just work on browser with HTML and JavaScript.
Re: (Score:2)
JavaScript downloaded from a Web site _is_ "untrusted applications". Soon HTML itself will be a full-blown progamming language.
Re: (Score:1)
Re: (Score:2)
> ...it shouldn't be able to affect anything outside of its sandbox.
Sure. Of course it shouldn't. And if it did, why that would be wrong.
Re: (Score:2)
How would HTML5 change that?
Re: (Score:1)
Re: (Score:3, Funny)
Just a little more duct tape will fix it. No need for a clean state redesign. With enough kludging, ever increasing performance of local clients and Internet connections, we'll make it work and look just like a local app did ten years ago. Some day.
- T. Roll
Apu: Please do not mock the power of duct tape. These are forces beyond the understanding of mere mortals.
The Web is not the Net. (Score:5, Informative)
> ...Internet Explorer, Firefox, and Chrome account for more than 90 percent
> of the usage on the Net...
The Web is not the Net.
Re: (Score:2)
Do they claim so? Browser usage is definitely what most people do on the Internet, so it might be either way. Especially as people moved from communication on IRC and IM to Facebook and other sites.
Re: (Score:3, Interesting)
> Do they claim so?
The browsers they list as having 90% of the Net have 90% of the Web. As there is more to the Net than the Web they are necessarily wrong.
> Browser usage is definitely what most people do on the Internet...
You forget spammers and botnet operators, both large and growing markets.
Re:The Web is not the Net. (Score:4, Funny)
You forget spammers and botnet operators, both large and growing markets.
Well, they'll just have to abide by the new HTML standards like the rest of us. What's fair is fair.
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
Re:The Web is not the Net. (Score:4, Funny)
> How do you find non-Web resources on the Internet other than through search
> engines on the Web?
I use Gopher.
Re: (Score:1)
> How do you find non-Web resources on the Internet other than through search
> engines on the Web?
I use Gopher.
Oh, and by the way, get the hell off my lawn!
FTFY
Re: (Score:2)
> Oh, and by the way, get the hell off my lawn!
Sonny, when I was your age we didn't have lawns. Grass hadn't been invented yet.
Error -420: Grass not found (Score:2)
Grass hadn't been invented yet.
Then what did you smoke to get high?
Re: (Score:2)
...or Usenet, or eDonkey, or Limewire, or...
Apple (Score:1, Troll)
Apple declined to comment about its support for IndexedDB.
However, if IE, Mozilla, and Chrome support Indexed DB, and it becomes a W3C standard, it's likely Apple won't have much choice, because programmers will begin to use it.
Happily for Apple, Google has detailed its approach in a Chrome design document and has begun checking Indexed DB code into WebKit, the open-source project that underlies both Safari and Chrome. That means Apple will be able to adopt a tested version of the technology relatively quickly.
Browser OS/webapps isn't really their market.
Personally, I reckon they are trying to work out who to sue.
Re: (Score:1)
> Personally, I reckon they are trying to work out who to sue.
Just be careful never to call it iNdexedDB (or bdDEXEDnI).
Slowly reinventing the wheel in the browser (Score:5, Insightful)
Congratulations, you've developed a framework for client-server application development. Welcome to 1990. But wait, it's different this time because it's lightweight? Only it's not. Your framework runtime (the browser) consumes many times the resources that existing client-server applications ever did, and you still can't provide the same level of functionality.
Progress in the software industry today looks like this:
- 2003: Microsoft releases Office 2003
- 2008: Google releases quirky, limited-functionality clone of Office 2003 that runs in the browser
- 2016: Google releases quirky but fully functional clone of Office 2003 that runs in the browser, only it's progress because it's Web 5.0!!!
Thanks but no thanks.
Re:Slowly reinventing the wheel in the browser (Score:5, Interesting)
When you look at much of the development of platforms, a great deal of effort has been expended to make sure that the programming model is simple. E.g., from the perspective of a typical process running in a typical modern OS, the world still looks like a simple OS: your own flat address space and simple system calls to use to write to disk, etc. Generally, you don't have to deal with interrupts, shared memory, etc. But networking is where all of this breaks down. The location of your storage is important, because while hard disks are slow, network storage is really slow. Some parts of your application run here, and some run there, and here and there may even be wildly different platforms (e.g., 'there' could be a functional language running on a cluster, while 'here' could be a mobile web browser on a cellphone), so race conditions and slow network links and processors are a real problem.
This constant shifting around is an attempt to find the right complexity balance. I don't know if there is a 'right' balance for all scenarios, but it doesn't look like that's going to stop people from trying to find it. Just look at all the iterations of RPC out there. They all suck, too (you just can't pretend the network doesn't exist!), but that does not stop them from being useful. Just look at NFS.
Re: (Score:2)
Of course we hate concurrency. That doesn't mean we don't need it.
Concurrency makes code nearly impossible to debug. We don't *like* Erlang. But without concurrency we can only execute in one hyperthread at a time, and that's slow.
Now if you throw in delays for IP connections, handling sockets that might or might not be there, etc. .... now you're getting to a place where most applications are better off avoiding. Yeah, there are toolkits and frameworks to make dealing with it plausible, and to ensure t
Re: (Score:2)
Concurrency makes code nearly impossible to debug.
Then you're probably doing it wrong. But I'd certainly not characterize it as being particularly easy. Key issues are that you need to avoid shared state (shared state concurrency is very difficult to debug) and you need to beware of global problems like deadlocks and livelocks; not everything can be solved just by looking at individual threads.
But if you keep the level of separation between different concerns strong, with every piece of state having a clear single owner at a time, you avoid most problems.
We don't *like* Erlang. But without concurrency we can only execute in one hyperthread at a time, and that's slow.
O
Re: (Score:2)
Erlang is slow compared to Python. And it doesn't have much in the way of graphics support.
If you aren't using Erlang, and you segregate out all the timing dependencies carefully, then you've just eliminated most of the benefit of concurrency. Ideally you'd like to be able to execute most loops in parallel...but it's only really worth doing for loops that do a lot of calculation. So, with any normal language, you've got to refactor those loops into something that looks completely different. Etc.
Go looks
Kinda necessary (Score:2)
The Web is better (Score:4, Insightful)
I think you're wrong. Functionality is not the name of the game. Communication and content are. Look, I was doing client-server development in the 1990s: Mac Programmer's Workshop (C++), Unix sockets (C), Microsoft Foundation Classes (C++). I would never go back. True, your example does illustrate your point. There are whole classes of application, like word processors, for which the Web is not (currently). But those are mostly stable, well-defined categories. The Web is not a better way to write Word, but it is a better way to create other software we want even more.
1. The Web is social. When you develop an application, communication between users is practically a given. Back in the day, client-server software was deployed within organizations and was focused on access to data or business processes. Communication was rare and tended to be limited.
2. The web centers on content to which developers add various functionality. You may have to work harder on your applications controls, but HTML and CSS give you tremendous power. A framework like Flash or .NET may let you put things exactly where you want them, but this takes flexibility (e.g. text sizing) away from the user. And they are still missing significant chunks of what HTML+CSS can do.
3. The Web is simple. The learning curve for web applications is dramatically lower than for the kinds of apps you are talking about. HTML gives you hyperlinks for free. It also gives you a history with forward/back buttons, bookmarkable URLs, and a world of users who have been trained to use them. Programmers who try to develop apps without these features loose out on core benefits of the Web (hello, Flash).
4. The Web is relatively unified and transparent. I can view source on any page, or if that doesn't work use Firebug to break down the DOM. These days the standards are complex, but there are real advantages over a mess of competing frameworks. Browser implementations are inconsistent: but that beats writing client-server software that works on some mix of Mac, Windows, and assorted Unix flavors, then trying to persuade the wider world to install client software.
5. Javascript doesn't suck. I was surprised too when I found this out. It has some real weaknesses for sure (dynamic scoping!). It's no Python or Ruby, but it is powerful and its idiosyncrasies pale beside, say, C++ or PHP. Perhaps its biggest flaw is the pathetically poor standard library.
If you want to write a word-processor, the weaknesses of the Web compared to traditional client-server development may be very frustrating. You could still go with client-server, which seems like the right tool for the job. But you don't. The advantages of the Web are overwhelming. It's easier to be nostalgic about the benefits of client-server than to reinvent the benefits of the web.
Dynamic Scoping? (Score:3, Informative)
It has some real weaknesses for sure (dynamic scoping!).
Of all the things to pick on... dynamic scoping? Javascript'd be a harder language to work in without it... you'd essentially be getting rid of closures.
Re: (Score:2)
Excuse my ignorance, but aren't closures by definition an implementation of static scoping?
Re: (Score:2)
I am not "nostalgic" about the benefits of client-server apps, they are what business needs for head-down handling of data in a manner that does not require a 50,000 line mashup of javascript, html, xhtml, xml and bloody css.
Browser implementations are worse then inconsistent, they are insane. One does it just every so slightly different then the other and your app fails in the land of the web browser.
But not to worry, the project for the application browser has begun. It will present a clean well defined
Re: (Score:2)
Because I shouldn't have to. The fucking control EXISTS in the form and its value should fucking be returned, just like any other control! Really I want to find the little biotch who decided this was "clever" and beat their ass!
Re: (Score:2)
Hmmm lets see.... How about returning "1" or "0"... Or perhaps "t" or "f", "T" or "F", "y" or "n"
In your terms why not just ONLY return the defined controls that have actual data in them?
How many CPU cycles does isset() consume?
In php parlance I have to invoke two functions, $_POST[] and isset(), how much more additional overhead is required? In a single instance it is more then likely negligible, but if I have 1000 users all hitting the same server, what is the additional overhead? IMHO that is the pr
Re: (Score:2)
To check to see if data is there? Post is defined as returning the control and it's associated data, even if the data is null, well with one glaring exception.
And if you want to go deeper into how badly the DOM was conceived, why isn't a text area are an input element? It is used to capture multi-line text input all the time, we have both used exactly that way. But if in JavaScript you want to ripple through all the input controls, guess what text area's do not show up. DOM has serious problems that nee
Re: (Score:2)
Read much?
...you have a query ready to be sanitized before it is passed onto the database server.
Re: (Score:2)
Game over, thanks for playing, no refund for you.
It was an example of why the UA should return ALL the controls WITH their associated data.
Re: (Score:2)
Re: (Score:1)
For the most part, but Google Office has some advantages. Multiple people editing the same document at the same time can be really powerful.
Re: (Score:1)
Web programming has always felt to me like a failed attempt at reinventing X11.
Except the web works on dialup links whereas X11 feels sluggish on my 10/100 network
Re: (Score:2)
The Application Browser will install in user space, require no system privileges, maintain its own lib's and dll's in its own directory space and more importantly it will be lightweight, fast and very very small. It will stay the hell out of the windows registry and stay the hell out of the etc directory. It will keep everything it needs local.
I must have missed something (Score:1)
Isn't local storage part of HTML 5?
Re:I must have missed something (Score:5, Informative)
Yes, and I've already written apps using it. Safari supports the html5 local storage pretty well, including in the iPhone.
I, too, am unsure how this differs from other new local db storage techniques.
What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determin if you are currently web connected, something like isNetConnected() found in some applications. This would let you customize the option you present to the user (ie, you can only sync your data when you're web connected).
Re: (Score:2)
I, too, am unsure how this differs from other new local db storage techniques.
Since they couldn't decide on what version of SQL dialect to use for Web SQL they're abandoning it for this new and improved idea developed by someone at Oracle. With Oracle's attitudes about licensing how could this be anything but the perfect solution?
What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determin if you are currently web connected, something like isNetConnected() found in some applications. This would let you customize the option you present to the user (ie, you can only sync your data when you're web connected).
For this I generally use an XMLHttpRequest for a tiny file. If I get my "200" I'm connected, if I don't I'm not.
Re: (Score:3, Informative)
Why? Just make a request to your webserver. Even if you are connected to the "Internet", if you can't access your server you won't be able to sync.
Re: (Score:2)
Why? 'cause while it is possible to do in javascript, the appropriate place for it is the application/browser.
Re: (Score:3, Informative)
But the browser doesn't know how your app works! What about if your domain is accessible, but the URLs that provide the webservice your app needs isn't?
You'd have to provide an URL anyway, so the abstracted code would be something like:
function isNetConnected(url) {
request.open("GET", url, false);
request.send(null);
return (request.status == 200):
}
I don't find this to be "REALLY useful".
Re: (Score:2)
I'll stick to my guns, having created apps using local data for mobile use. Having the ability to detect net connection would be really useful.
While it's possible to hack this together in javascript, getting system status information from a try/catch type block executed in an asyncronous fashion leads to false positives, false negatives, and code that's generally difficult to debug.
It's not important that it works for you, it's important it work in the field.
A simple synchronous javascript API that allows t
Re: (Score:2, Informative)
What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determine if you are currently web connected.
You mean something like
var online = navigator.onLine
as defined in http://www.w3.org/TR/offline-webapps/#related [w3.org] ?
I'm glad Microsoft is involved in the early stages (Score:4, Insightful)
so they have plenty of time to plan the (seemingly) minor but maddeningly frustrating ways they'll deviate from the standard.
Re: (Score:1)
mod parent up, we've all been there, wait, we are still there.
Re: (Score:2)
You would prefer IE to just use MSSQL CE?
Need to decouple Javascript before it's too late (Score:5, Insightful)
And I see that our options as developers for interacting with this stunning new invention are still limited to one: Javascript.
With application development increasingly moving to the browser, we as developers are going to find ourselves locked into a one language platform.
The browser platform should standardize on a VM, not on a language. Say goodbye to traditional paths of evolution of programming languages driven by competition. Want to innovate by using a functional language to bring your solution to market faster? No can do. It's JavaScriptway or the highway.
Re:Need to decouple Javascript before it's too lat (Score:1)
Re: (Score:2, Interesting)
Re: (Score:3, Informative)
Want to innovate by using a functional language to bring your solution to market faster? No can do.
That's not entirely true - you could write in Haskell and compile to JavaScript [haskell.org].
Re: (Score:2)
Yes, I could also burn my own eyes out with a cutting torch but why would I want to!
Re: (Score:3, Interesting)
Not entirely true. Technically xslt is a programming language and is supported by many browsers. I know of at least one person writing an XML/XSLT CMS.
It's too late (Score:3, Insightful)
Want to innovate by using a functional language to bring your solution to market faster? No can do.
If you're familiar enough with functional language F (and JavaScript) to be justifiably snobby about JavaScript's status as a functional language and suggesting a VM as a solution, you shouldn't have much trouble writing an F-to-JavaScript compiler.
(If you do, then you likely fail the "justifiably" part of the snobby criteria, and you're also probably not likely to get a jump on that time-to-market measure, g
Re: (Score:3, Insightful)
Maybe we could create a VM based language designed for networked applications, with a full blown security model down to the bytecode and performance as good as a static language.... And to make people comfortable we could name it something that sounds like JavaScript... I dunno... like Java.. Java... I can't think of one :)
Oh, and then Microsoft can adopt it just enough to completely derail it and prevent it from becoming useful in the browser market... And Sun can let the UI and media implementations la
Re: (Score:2)
Maybe we could create a VM based language designed for networked applications, with a full blown security model down to the bytecode and performance as good as a static language.... And to make people comfortable we could name it something that sounds like JavaScript... I dunno... like Java.. Java... I can't think of one :)
Oh, and then Microsoft can adopt it just enough to completely derail it and prevent it from becoming useful in the browser market... And Sun can let the UI and media implementations lag permanently 5 years behind because it doesn't help them sell more server hardware... And the whole thing can just fester until Google comes along and teams of the smartest people in the world waste years of their lives building a layer of sanity over the JavaScript mess that is acceptable enough to write apps for...
Java had almost everything right, but failed utterly on two important fronts:
- slow initial load time of the interpreter.
- GUI designers for layout and graphical elements
The first problem still hasn't be solved, and it's been more than a decade. When the Java plugin starts, everything grinds to a halt. What's even worse is that I have a fast dual-core CPU and a high-end SSD, and it still takes forever for that thing to load. Meanwhile, .NET apps and Flash both start instantly.
The second problem is only now
Re: (Score:2)
- slow initial load time of the interpreter.
- GUI designers for layout and graphical elements
True... although third parties would have sprung up to take care of the GUI designer issue if there had been more demand. Sun did make attempts in this area, but they couldn't overcome their earlier mistakes.
The slow startup issue could have been addressed earlier with a resident VM strategy... but they wanted to wait for an perfect isolation API... and they wasted a decade on that and it never mattered.
The bigger problem though was going with a native AWT from the start instead of a mostly Java implementation like the current Swing. Netscape wanted a native look and feel so they caved and put out this mess that was the original AWT that didn't work consistently across platforms and wasn't truly extensible... and that was a lot of people's first exposure to Java. Then Microsoft froze progress there in their browsers and the rest is history.
Re:Need to decouple Javascript before it's too lat (Score:2)
Which is why it makes an easy target for a Scheme compiler, right?
http://github.com/dyoo/moby-scheme [github.com]
http://planet.plt-scheme.org/display.ss?package=moby.plt&owner=dyoo [plt-scheme.org]
http://www.cs.brown.edu/~sk/Publications/Talks/Moby-Bootstrap/ [brown.edu]
Death of Web as I know it. (Score:3, Insightful)
The day I as user would not be able to resize browser window, adjust font size or copy-paste any random text from a page, will be the death of the web as I concerned.
Indexed DB/etc is OK - but rest of the carp they do under the guise of making web seamlessly integrating with the desktop is a huge leap back.
Some people has to sit for a moment and recall why web applications started winning over desktop applications.
Users like the division (Score:2)
Web as application delivery mechanism (Score:2)
But with this web stuff, now, if I want to persist data, I need to do
if you want to reinvent the wheel, do it right! (Score:2)
another idea
Re: (Score:2)
Damn and here I am with no mod points. +10^6 insightfull!!!!! You GO boy!
Re: (Score:2)
Damn and here I am with no mod points. +10^6 insightfull!!!!! You GO boy!
Wow, here I was thinking I've been getting a lot of mod points lately - but you've got me beat by several orders of magnitude!
Cookies on steriods (Score:1)
This is so ass backwards (Score:2)
I have an idea. Let's create a lightweight desktop app that can browse the web and stream audio/video, upload/download files, and submit text for online shopping, and posting to Slashdot. Let's call it web... err... uhmm... web browser. Yeah, that's it. Let's call it a web browser.
If we need to do anything more, develope a "helper application". Even better; an internet-enabled app that avoids screwing around with my browser altogether. I don't know about everybody else here, but I was around in the da
Re: (Score:3, Informative)
Re: (Score:2)
1 Introduction This section is non-normative. This specification introduces two related mechanisms, similar to HTTP session cookies, for storing structured data on the client side. [COOKIES] The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.
Hokay...
Someday the W3C is going to learn how to write I think. You know, in a human language, where the laws of physics apply. Non-normative indeed.
Re: (Score:2)
Re: (Score:2)
Yep, and if they didn't recommend a space limit of 10 megs, it might almost be useful.
Re: (Score:1)
Good news, no one will force you to participate. Isn't it great? You get to ignore it because you hate it, and those of us who don't hate it get to not be ignorant. Life is grand with choice.
Re: (Score:3, Insightful)
Re: (Score:2)