Oh, that's not what AJAX is for at all, though many morons may use it that way. endlesspage is a great example of what AJAX can be used for, allowing a faster page load/render time by delivering a screenful at first, then getting the additional pieces as the user scrolls. Or displaying information in response to user input, that is not needed for every page load. That is what it is for.
Template rendering via AJAX in the client is pure foolishness. If you have coded your backend properly, your app only generates a given page once (until it is updated, of course), keeps a copy on disk, and points the web server to the copy when it asks. Of course, you front-end it with a caching proxy so your app doesn't get asked much, and load the box up with gobs of RAM so the file system buffers everything the proxy is looking up, but I digress. My point is: Why would you want every user to pay for template processing time for every page view, on their likely inferior CPU, when you can get the page rendered faster for them by doing it just the once in the backend, and just pipe some gzipped HTML to them?
Did I read what you said correctly? You're doing form input validation via AJAX? If so, you most certainly are correct in your initial assertion that you haven't been doing this very long.
No way man, websites designed like that have a persistence of vision effect that makes it extremely difficult to read any of the other windows on my computer for like 30 seconds. Poorest choice in web design. Now, I am all for using bigger fonts. Too many people are in denial about their need for glasses, so small fonts == lost customers.
I had two instrumentation approaches for debugging asynchronous events.
First: send 1 letter at a time out an aysnc port to another computer that captured it. Different letter for each event. After collection, dump the data into a file and run another program that would expand the 1 letter codes into a single line of text. Usually that would give some kind of clue as to what was stepping on what.
Second: same thing but use a ring buffer in RAM. At a certain point, I ran across a problem where the interrupts of shoving characters out the async port would change the timing of the system enough to mask the problem. That one I had to do by hand as the system was usually toast, so no way to dump the event trace to a file.
I miss those good old days too. My path took me toward using the logic analyzer to debug the hardware guys' circuits. They just didn't understand things like why we needed them to latch the interrupt request signal and creating additional status registers and stuff like that. I ended up being able to keep the soldering iron I used back in those days, and I still use it on occasion.
The floppies we used on that system had a sector interleave of 4 to maintain backward compatibility with a time when the computers were so slow they couldn't keep up with the floppy spinning. I rewrote the floppy BIOS to read sectors out of order (or actually, in the order they appeared on the disk), so one track was read in a single revolution. The boss cursed me for wasting time like that, but I really just couldn't tolerate waiting sooooo long to back files up to floppy. He later thanked me.
I started working with those guys when I was 17. We made multiprocessor CP/M systems, back before there were ethernet cards available for the PC, and Novell had not even hit the scene yet. Those guys really taught me a lot.
Even still, I believe switching screens even in the primitive way CCP/M did would be enough to establish prior art. That is all that a desktop switcher does, it sweep the contents of one screen away and replaces it with another.
Digital Research created two products in the 80's, Concurrent CP/M and Concurrent DOS, which had a multi-view aspect to the user interface. You could run 4 text-based applications simultaneously and switch between them using a hotkey. (Alternatively, you could also custom code an XIOS to connect each process to an individual terminal and timeshare, which is something we did at the first place I worked) I'm fairly certain Concurrent CP/M was available prior to this patent being filed.
Who put the "on mm/dd/yy-----" bullshit back into the headline portion of an article display? This is totally stupid, redundant, and I was pretty glad when I noticed that someone backed it out about a week ago.
I've found this is the most effective way to piss off the jackass in the Prius going 65 in the fast lane. Start drafting 'em. They get out of the way quick when they realize I am sucking their fuel efficiency over to my ride, like my car is some kind of mechanized vampire.
Reminds me of the time my buddy and I were playing some 301 at the dart board. Both of us were pretty wasted. I discovered he couldn't subtract, and that was giving him an advantage, so I started keeping score. Then we discovered I also was too wasted to subtract.
We decided I would sit down and code a score keeping program with a text-based GUI (similar to ye olde Vitamin C Screen Utilities). Each player just entered their darts 10, 13, etc. or D20 for a double 20 T13 for triple 13, and B/DB for bullseye and double bull, then the code would do the math. Apparently writing a parser and an event loop with some event handlers taps a part of my brain unhindered by all the alcohol, etc.
Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.
Obviously, you don't write much HTML. Web authors would prefer a monolithic rendering system, rather than the hodgepodge of nearly-standards-compliance we have now. Face it, you're never going to get the same results out of multiple rendering engines, without resorting to the black art of navigating bugs in different browsers.
WebKit has shown it's chops in fast rendering, small size, portability, etc. Everyone should just adopt it. Let it be the standard. Let the specs evolve and implement the new specs in WebKit, then relink your code, and voila, every browser now has the updated standard.
The Mozilla crew are still pissed at David Hyatt for choosing Konqueror over Gecko as "the best open source rendering engine available" when he defected from Mozilla to Apple.
That's why they will never consider WebKit. Too much pride.
Well, I have to agree with the "clueless PC dweebs" assertion, but for a totally different reason. The real test of an SSD is how well it handles overlapped reading and writing, ya know, to see if the system starts stuttering when it tries to read swap while the drive is busy writing data. There are some numerous threads about this performance issue floating around out there. Too bad these guys didn't take the bull by the horns, but then again, why should they? Their review was likely bought and paid for, and measuring read/write overlap always reveals SSD to be inferior to standard magnetic drives.
Genius: do you own an Apple Product? Moron: uh, um, no. Genius: Next!
or
Genius: do you own an Apple Product? Moron: yes, here's my iPhone 3G. Why don't you guys support XYZ Genius: Use the source, put your app on the AppStore
Slashdot Mirror
Oh, that's not what AJAX is for at all, though many morons may use it that way. endlesspage is a great example of what AJAX can be used for, allowing a faster page load/render time by delivering a screenful at first, then getting the additional pieces as the user scrolls. Or displaying information in response to user input, that is not needed for every page load. That is what it is for.
Template rendering via AJAX in the client is pure foolishness. If you have coded your backend properly, your app only generates a given page once (until it is updated, of course), keeps a copy on disk, and points the web server to the copy when it asks. Of course, you front-end it with a caching proxy so your app doesn't get asked much, and load the box up with gobs of RAM so the file system buffers everything the proxy is looking up, but I digress. My point is: Why would you want every user to pay for template processing time for every page view, on their likely inferior CPU, when you can get the page rendered faster for them by doing it just the once in the backend, and just pipe some gzipped HTML to them?
Did I read what you said correctly? You're doing form input validation via AJAX? If so, you most certainly are correct in your initial assertion that you haven't been doing this very long.
No way man, websites designed like that have a persistence of vision effect that makes it extremely difficult to read any of the other windows on my computer for like 30 seconds. Poorest choice in web design. Now, I am all for using bigger fonts. Too many people are in denial about their need for glasses, so small fonts == lost customers.
"Can't wait till they come out with the 300 baud version"
I detect an unusually high occurrence of the number three.
I had two instrumentation approaches for debugging asynchronous events.
First: send 1 letter at a time out an aysnc port to another computer that captured it. Different letter for each event. After collection, dump the data into a file and run another program that would expand the 1 letter codes into a single line of text. Usually that would give some kind of clue as to what was stepping on what.
Second: same thing but use a ring buffer in RAM. At a certain point, I ran across a problem where the interrupts of shoving characters out the async port would change the timing of the system enough to mask the problem. That one I had to do by hand as the system was usually toast, so no way to dump the event trace to a file.
I miss those good old days too. My path took me toward using the logic analyzer to debug the hardware guys' circuits. They just didn't understand things like why we needed them to latch the interrupt request signal and creating additional status registers and stuff like that. I ended up being able to keep the soldering iron I used back in those days, and I still use it on occasion.
The floppies we used on that system had a sector interleave of 4 to maintain backward compatibility with a time when the computers were so slow they couldn't keep up with the floppy spinning. I rewrote the floppy BIOS to read sectors out of order (or actually, in the order they appeared on the disk), so one track was read in a single revolution. The boss cursed me for wasting time like that, but I really just couldn't tolerate waiting sooooo long to back files up to floppy. He later thanked me.
I started working with those guys when I was 17. We made multiprocessor CP/M systems, back before there were ethernet cards available for the PC, and Novell had not even hit the scene yet. Those guys really taught me a lot.
Even still, I believe switching screens even in the primitive way CCP/M did would be enough to establish prior art. That is all that a desktop switcher does, it sweep the contents of one screen away and replaces it with another.
Digital Research created two products in the 80's, Concurrent CP/M and Concurrent DOS, which had a multi-view aspect to the user interface. You could run 4 text-based applications simultaneously and switch between them using a hotkey. (Alternatively, you could also custom code an XIOS to connect each process to an individual terminal and timeshare, which is something we did at the first place I worked) I'm fairly certain Concurrent CP/M was available prior to this patent being filed.
Who put the "on mm/dd/yy-----" bullshit back into the headline portion of an article display? This is totally stupid, redundant, and I was pretty glad when I noticed that someone backed it out about a week ago.
What? No death threat?
I think it also explains why sales on the website of my family's business were cut in half today.
That's cool, I love wogs like you. I let you slow down, drop it into 4th, then put you where you belong, in the small part of my rear view mirror.
Ok, I stand correc~1 on the vampiring issue. It works though, every time.
I've found this is the most effective way to piss off the jackass in the Prius going 65 in the fast lane. Start drafting 'em. They get out of the way quick when they realize I am sucking their fuel efficiency over to my ride, like my car is some kind of mechanized vampire.
Reminds me of the time my buddy and I were playing some 301 at the dart board. Both of us were pretty wasted. I discovered he couldn't subtract, and that was giving him an advantage, so I started keeping score. Then we discovered I also was too wasted to subtract.
We decided I would sit down and code a score keeping program with a text-based GUI (similar to ye olde Vitamin C Screen Utilities). Each player just entered their darts 10, 13, etc. or D20 for a double 20 T13 for triple 13, and B/DB for bullseye and double bull, then the code would do the math. Apparently writing a parser and an event loop with some event handlers taps a part of my brain unhindered by all the alcohol, etc.
They're still around?
Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.
Obviously, you don't write much HTML. Web authors would prefer a monolithic rendering system, rather than the hodgepodge of nearly-standards-compliance we have now. Face it, you're never going to get the same results out of multiple rendering engines, without resorting to the black art of navigating bugs in different browsers.
WebKit has shown it's chops in fast rendering, small size, portability, etc. Everyone should just adopt it. Let it be the standard. Let the specs evolve and implement the new specs in WebKit, then relink your code, and voila, every browser now has the updated standard.
The Mozilla crew are still pissed at David Hyatt for choosing Konqueror over Gecko as "the best open source rendering engine available" when he defected from Mozilla to Apple.
That's why they will never consider WebKit. Too much pride.
Makes sense to me... We already know the random access on an SSD blows standard HDDs out of the water (Three of the drives are 1 MS access).
not so much, really
Well, I have to agree with the "clueless PC dweebs" assertion, but for a totally different reason. The real test of an SSD is how well it handles overlapped reading and writing, ya know, to see if the system starts stuttering when it tries to read swap while the drive is busy writing data. There are some numerous threads about this performance issue floating around out there. Too bad these guys didn't take the bull by the horns, but then again, why should they? Their review was likely bought and paid for, and measuring read/write overlap always reveals SSD to be inferior to standard magnetic drives.
It's all about reducing drag.
It's work for hire...the company owns it. Pretty simple.
You'll be fired, and they'll file the patent anyway.
Genius: do you own an Apple Product?
Moron: uh, um, no.
Genius: Next!
or
Genius: do you own an Apple Product?
Moron: yes, here's my iPhone 3G. Why don't you guys support XYZ
Genius: Use the source, put your app on the AppStore
with such juvenile tactics that the free software movement continues to fail in its efforts to gain wider acceptance.
Time to rename the FSF to the Fascist Software Foundation. BSD License FTW!