This is actually not a problem with SSL. It's a basic flaw in the design of X.509 (the certification spec that SSL uses), and has been known and talked about from the beginning. You have critical policy information (e.g., the "basic constraints" certificate extension) being expressed in a credential, but the consumer of that credential may or may not interpret the information correctly. The lesson here (which gives the lie to all the PKI hype) is that you cannot separate certification policy from application policy.
I wrote a book in LyX and would do the same again. LyX's structured environment saved me many hours of formatting and cross-referencing. There is also no other way that I know of to get the same quality of output. My publisher uses Word for copy editing (many publishers do, apparently for no good reason), but it was a fairly small matter to convert the manuscript.
>> Quoting myself (for the third or fourth time now): "The Ajax answer is to keep all of the lobotomized >> bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the >> capabilities that were hacked off in the first place.
> Um, state is kept in sessions through the use of cookies. It has nothing to do with AJAX. Cookies are not > perfect (they may be turned off), but they are a far cry from Byzantine.
I'm sorry, I don't see anything about "state" in here, and I don't see where I said that cookies are Byzantine.
> So what you're trying to say is that server-based applications are garbage? That's not a foregone > conclusion. If you need a smart client code a smart client, that doesn't mean there aren't benefits to > doing things the other way.
Of course I'm not saying that server applications are garbage. I'm saying that application programmers should have choice.
> I can't point out anywhere where you say how web applications are procedural, I was just trying to guess > at your meaning. You just say "dumb xml data structures get passed to "stateless" objects (in other > words, procedures)". Only where are the stateless objects? The backend code is all object-oriented and > stateful, and the JavaScript code has the current view as its state. Where's the procedural code?
There is no context between the client and server, unless (as you point out) it's stored in cookies and session objects. We have therefore sacrificed the inherent statefulness of the underlying technologies (TCP and OO programming) and created additional mechanisms to make up for the loss.
>> So you're saying that if all of us clever technology types put our heads together, no one will be able to >> devise a content scheme that has more capability than HTML while remaining compatible with HTTP?
>> Web applications are about the most expensive development effort the world has ever seen. So my >> answer, with respect to any reasonable alternative, is, "less than the cost of a Web application."
> Of course someone can come up with a better idea. But that's 1% of the problem. Then you have to > implement it on every platform and have it shipping with every computer.
I never said (or implied) anything about any of this.
> Also where do you get the idea that web applications are so expensive? This is just your impression.
No, it's a fact. And it's very easy to see why: standards that are implemented differently in every browser and back-end, lack of interoperability (for example, take an arbitrary company X and try to plug its SOAP client into company Y's server), and absurd proliferation of technologies for achieving even simple tasks.
> The web's limitations may be its downfall when it comes to rich interfaces, but it's a strength when it > comes to speedy development and deployment of simple apps.
This, again, was not my point, but I'm in partial agreement with what you say. Web applications are easy if they're *very* simple.
>> On the other hand, I would like you to explain how asserting that something is badly designed >> constitutes pretention.
> No your disdain due to an assertion that I'm following a herd is pretentious.
It might have been if I'd said it. Saying that I'm bothered by herd behaviour is not the same as saying that you are following a herd.
>> I also never said that Web applications are "a poor copy of traditional client applications.
> Are you for real? Or am I just not allowed to summarize? The whole gist of your arguments was that web > applications are a 'lobotimization' of older technologies. I just assumed client applications, but maybe > you were referring to something else. Either way, your arguments by themselves are not cohesive, I have > to extrapolate somewhat to argue at all.
You d
Re:Amusing, but mostly wrong.
on
Ajax in Action
·
· Score: 1
I do not have to defend any remark that I never made.
If you think that I implied something, then you'll have to tell me what it is.
> Hm. A system that reliably transfers files from server X, Y, and Z simultaneously to your computer. > Three at once. Reliably. Sounds kinda cool, no?
I never said that it wasn't, nor that there were not good reasons for doing things this way at the time.
>> Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data >> structures get passed to "stateless" objects (in other words, procedures), and all processing must >> happen at one end of the connection. This is Web applications.
> Perhaps you're confusing Java and Javascript?
Perhaps you are. A Web application takes an object-oriented language and forces you to write stateless procedures on the server. It then passes xml data structures to those procedures from the client.
>> Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a >> browser.
> So, before the browser, what technology was available that: > > 1) was cross-platform, > 2) allowed bits of information from all over the world to be rendered togeter, > 3) Included pictures and sound as well as text, > 4) Did all the above cheaply and reliably. > > I don't remember it, either.
I should hope not, because it didn't exist. Refer to my first comment, above.
>> So: having gone from a world of functional, stateful, distributed applications engineered to a true >> software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to >> procedural programming and dumb terminals (meaning Web browsers).
> What world are you thinking we came from? I remember when Kermit file transfer was a big advance...
Yes, indeed. These were low-tech applications built from pieces that were suited to the purpose. The original Web, by and large, was also built from suitable components. The problem is that it was too successful. We now have a situation where, in order for any application to gain distribution, it must somehow run in a browser - an object whose original function was simply to display content. What if gopher had been the successful application? Would it make any sense to continually paste more and more pieces onto gopher clients while claiming that it's the One True Way to write networked applications? Or would it make more sense to concede that the model had grown by aggregation, and perhaps it was time to consider other approaches?
>> In other words, 1970s technology with pictures.
> Your car uses a technology that's now provably thousands of years old - the wheel. Do you complain > about the age of this technology, or do you simply accept that it works?
It's fairly clear that my comment was about function, not age. Web applications lack true interactivity (among many other things), and are, metaphorically, similar to the 1970s model of mainframe computing.
>> Any half-wit can see that this situation is broken.
> Perhaps only half-wits see it this way. How did you post this article again? Oh, yeah, using 70s > technology! But you did it, didn't you? I read it, I responded. Neat, huh?
Not very. Message servers have existed for decades.
> It's not everyday that you end up with an application that: > > 1) Works no matter where you are, > > 2) Requires no additional install to work, > > 3) works with data from servers around the world, > > 4) Delivered in real time, on request, > > 5) Using stock, commodity hardware and communications technology.
These comments are about the Web, and as I've said already, I never disputed any of it. If, on the other hand, we're talking about Ajax proper (the subject of my posting), we could add:
6) is hideously complex to implement, to the point where most developme
It's encouraging to know that there are still some sane people out there.
Re:Amusing, but mostly wrong.
on
Ajax in Action
·
· Score: 1
1) The fact that you can keep a connection open and send multiple requests in one message does not make HTTP stateful. In any case, it's fairly obvious that I was making general observations about the evolution of Web technology, not inviting arguments about trivia.
2) I very clearly made no attempt to defend object-oriented technology, and the issue of concurrency has nothing to do with why Ajax is badly designed.
3) I made no assertion about how data should be shared, though your implication that RDBMS can solve all data-sharing problems is rather strange.
4) I made no attempt to defend GUIs, most of which suck.
>> I made no assertion one way or the other about HTML and HTTP being suitable for particular purposes. >> Eulogize all you want about the wonders of the Web. It has nothing to do with my point.
> Okay, well if it had nothing to do with your point then why even mention that HTTP is a 'lobotomized' > form of something else?
Quoting myself: "The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place."
> Nice ad hominem attack. That really proves your intelligence.
Gee, I'm sorry. I didn't realize that when you called me a Nazi you meant it in a nice way.
> Um, in case you didn't read your own comment, you said that the web is procedural because dumb data > is passed to 'stateless' objects.
And your response to this was, "This sentence is complete gibberish. Java is platform independent? Pretty close maybe."
> I explained that this is nonsense because there's nothing stateless about web applications. Yes, HTTP is > stateless. Therefore web applications implement state at a higher level. [etc.]
Quoting myself (for the third or fourth time now): "The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place."
> But what you didn't explain is why you need to pass objects to the client? Since everything is happening > on the server [. ..]
You've answered your own question here.
> The idea that software is not 'real' unless it's a client-server architecture with code being transmitted > across the network is extremely narrowminded.
Show me where I say this. Getting into a discussion with you about what's real and unreal would obviously be very foolish.
> Honestly, have you ever written a web application? If all your code is object-oriented, how is it that then > magically it is lobotomized by a transmission protocol and suddenly procedural. There's plenty wrong > with web development, but I'm afraid you're not getting it.
Again, I believe you've been listening to the voices in your head rather than to me. Can you point out where I say that a transmission protocol makes things procedural? When you say, "you're not getting it," which of us are you speaking to?
> Your problem is you don't seem to think there is any value to keeping your code on your server [. ..]
Of course there's value to doing this - if that's what is appropriate for my application.
> or distributing your application by means of a URL that anyone can type in to instantly access your > application
Where did I say this? Quote me, please.
> or tight integration with tons of other applications on the same platform.
Ah, then maybe I don't get it after all. Maybe you could show me the setting that allows me to drag an "object" from my google map onto a message I'm composing in gmail and have the object ask me if I want to include directions from the recipient's house. A theoretical explanation will suffice.
> Or maybe you just think there is a better way of achieving these benefits. Well call me when the better > solution is out there.
Okay. What's your number? Seriously.
Look, I'm going to be nice for a moment despite all the names you called me. I am not criticizing people who write Web applications. I am not even criticizing (at least not stongly) the Web as it was originally conceived. I am, instead, saying that Ajax (as a technology, not as a way to make a living) is like trying to paste a Chevy Suburban onto a blender in order to produce a space shuttle. It simply violates common sense. Yes, you can make it do certain things, and I expect we'll probably see a lot more of
Yes, I have a grudge against all of the institutional stupidity that drives the technology industry.
1) I made no comment whatsoever about http's reasons for being stateless. If you think it's a "Good Thing," I couldn't care less.
2) If you actually read my posting, you will find that I also said nothing about ajax being stateless. I said that it layers a lot of complicated nonsense on top of the existing Web mess in order to compensate for capabilities that the underlying layers engineered out.
3) "Processing appropriate to the client" does *not* take place on the client in an ajax "application." What takes place on the client is whatever processing the framework allows.
4) Yes, a "real programmer" (as you put it) can make Ajax clients and servers cooperate to some extent. A real programmer can also write a 3-d game in assembly language.
5) If, again, you actually read my posting, you will see that I say nothing about ajax refreshing entire screens. Refer to #2. I agree, however, that someone has missed the whole point.
Re:About your proposed revolution
on
Ajax in Action
·
· Score: 1
Independent thinking is not at all easy. I have never known a teenager to do it; on the contrary, teenagers are among the strictest conformers on earth.
Is your point that revolutions are hard, therefore everyone should just conform?
But if you were really making an honest request to see an alternative to Ajax, then fair enough. The fact is that there are many alternatives (once you start considering the problem from its root). If you would like to see one that *really* works, I'd be glad to show you. Unfortunately, I'm not willing to discuss it in this forum.
There's a contact link on my company's Web site: www.ektasis.com. If you send an e-mail through the link, I'll be glad to invite you over for some show and tell.
Oh please - not another true believer saying "Oh please" and pretending to refute an argument by using dramatic words like "tired" to imply that it has already been refuted.
1) I made no assertion one way or the other about HTML and HTTP being suitable for particular purposes. Eulogize all you want about the wonders of the Web. It has nothing to do with my point.
2) Yes, Java is "pretty close" (in your own words) to being platform independent. So if my sentence is gibberish, then you are also spouting gibberish. In either case, I used the term "platform independent" simply as an adjective describing Java. Had you been able to hold my entire sentence in your little head at once, you would have seen that my point was about "object oriented" vs. "procedural," not "platform independent" vs. "platform dependent." So again, you are driveling on about irrelevancies.
3) I don't care whether your data structures are XML or PMS. An intelligent reader would have discerned my point: they are *data structures*, not objects. An object can also be just data if you want it to be; in fact, serialized Java objects (as an arbitrary example) *are* just data, in the sense that only the object *state* is serialized (so your rant about "Why pass bloated objects and more code . ..," etc. is simply wrong). The point is that real software gives you a choice.
4) My contention is precisely that Ajax attempts to simulate an object-oriented model by layering hideously complicated sets of stuff on top of a pre-existing structure that is not itself object oriented (or, more precisely, used to be object oriented until it was lobotomized). So where you go on about "object orientedness" having "nothing to do with the underlying protocols," I thank you for your support.
5) Yes, we all know that Javascript puts "view" code in the browser. Bully for you. And I apologize for not being sufficiently excited that my Web applications force me to take nearly the entire processing load on my server while the client's 3GHz machine sits idle waiting for a picture to paint. I will try to imitate your macho stoicism by meditating on the fact that my application code has the privilege of staying "in a controlled environment where it is secure." While I do this, I will also try to avoid any unpleasant questions about the security of my browser.
6) You go on quite a bit about Java objects and such. I couldn't care less about Java in particular, but what you say (namely, that Java cannot do "much we can't do just as easily now") is absolutely true (though it's a bit beyond me why it needs stating that Java can't do anything that software can't do). Ajax, on the other hand, is capable of doing considerably less.
7) Yes, HTML is simpler than writing a gui. Perhaps you can explain how this relates to what I said.
8) Regarding dumb terminals, go learn what a metaphor is. I forgive you for not knowing. As you say, "This is pure ignorance."
But honestly. Why pick nits at a time like this. You have provided me with a profound revelation. Your point about "abstraction" has helped me see the light. I realize now that I have been misled all my life concerning the meaning of this word. I always thought it had something to do with encapsulating logic so that people could write more functional applications. I see now (with your help, for which I am deeply grateful) that it's really about encapsulating things so that people can write *less* functional applications. I'm going to sign off now so that I can pan around my google map and reflect on how awe-inspiring it is.
You are so right. I'll stop pining for my compilers immediately and join the herd.
Re:About your proposed revolution
on
Ajax in Action
·
· Score: 1
It seems you already have religion, so why do you want a revolution? Or maybe you were reading the wrong posting because mine only implied a wish: that "technology" people stop acting like herd animals and actually fulfill their reputation as independent thinkers. Or is that hype too?
Ajax Killed Himself
on
Ajax in Action
·
· Score: 5, Insightful
Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser.
So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken.
How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place.
Brilliant.
Slashdot Mirror
This is actually not a problem with SSL. It's a basic flaw in the design of X.509 (the certification spec that SSL uses), and has been known and talked about from the beginning. You have critical policy information (e.g., the "basic constraints" certificate extension) being expressed in a credential, but the consumer of that credential may or may not interpret the information correctly. The lesson here (which gives the lie to all the PKI hype) is that you cannot separate certification policy from application policy.
I wrote a book in LyX and would do the same again. LyX's structured environment saved me many hours of formatting and cross-referencing. There is also no other way that I know of to get the same quality of output. My publisher uses Word for copy editing (many publishers do, apparently for no good reason), but it was a fairly small matter to convert the manuscript.
>> Quoting myself (for the third or fourth time now): "The Ajax answer is to keep all of the lobotomized
>> bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the
>> capabilities that were hacked off in the first place.
> Um, state is kept in sessions through the use of cookies. It has nothing to do with AJAX. Cookies are not
> perfect (they may be turned off), but they are a far cry from Byzantine.
I'm sorry, I don't see anything about "state" in here, and I don't see where I said that cookies are Byzantine.
> So what you're trying to say is that server-based applications are garbage? That's not a foregone
> conclusion. If you need a smart client code a smart client, that doesn't mean there aren't benefits to
> doing things the other way.
Of course I'm not saying that server applications are garbage. I'm saying that application programmers should have choice.
> I can't point out anywhere where you say how web applications are procedural, I was just trying to guess
> at your meaning. You just say "dumb xml data structures get passed to "stateless" objects (in other
> words, procedures)". Only where are the stateless objects? The backend code is all object-oriented and
> stateful, and the JavaScript code has the current view as its state. Where's the procedural code?
There is no context between the client and server, unless (as you point out) it's stored in cookies and session objects. We have therefore sacrificed the inherent statefulness of the underlying technologies (TCP and OO programming) and created additional mechanisms to make up for the loss.
>> So you're saying that if all of us clever technology types put our heads together, no one will be able to
>> devise a content scheme that has more capability than HTML while remaining compatible with HTTP?
>> Web applications are about the most expensive development effort the world has ever seen. So my
>> answer, with respect to any reasonable alternative, is, "less than the cost of a Web application."
> Of course someone can come up with a better idea. But that's 1% of the problem. Then you have to
> implement it on every platform and have it shipping with every computer.
I never said (or implied) anything about any of this.
> Also where do you get the idea that web applications are so expensive? This is just your impression.
No, it's a fact. And it's very easy to see why: standards that are implemented differently in every browser and back-end, lack of interoperability (for example, take an arbitrary company X and try to plug its SOAP client into company Y's server), and absurd proliferation of technologies for achieving even simple tasks.
> The web's limitations may be its downfall when it comes to rich interfaces, but it's a strength when it
> comes to speedy development and deployment of simple apps.
This, again, was not my point, but I'm in partial agreement with what you say. Web applications are easy if they're *very* simple.
>> On the other hand, I would like you to explain how asserting that something is badly designed
>> constitutes pretention.
> No your disdain due to an assertion that I'm following a herd is pretentious.
It might have been if I'd said it. Saying that I'm bothered by herd behaviour is not the same as saying that you are following a herd.
>> I also never said that Web applications are "a poor copy of traditional client applications.
> Are you for real? Or am I just not allowed to summarize? The whole gist of your arguments was that web
> applications are a 'lobotimization' of older technologies. I just assumed client applications, but maybe
> you were referring to something else. Either way, your arguments by themselves are not cohesive, I have
> to extrapolate somewhat to argue at all.
You d
I do not have to defend any remark that I never made.
If you think that I implied something, then you'll have to tell me what it is.
> Wow. Very sardonic. Point-by-point:
Point by point:
> Hm. A system that reliably transfers files from server X, Y, and Z simultaneously to your computer.
> Three at once. Reliably. Sounds kinda cool, no?
I never said that it wasn't, nor that there were not good reasons for doing things this way at the time.
>> Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data
>> structures get passed to "stateless" objects (in other words, procedures), and all processing must
>> happen at one end of the connection. This is Web applications.
> Perhaps you're confusing Java and Javascript?
Perhaps you are. A Web application takes an object-oriented language and forces you to write stateless procedures on the server. It then passes xml data structures to those procedures from the client.
>> Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a
>> browser.
> So, before the browser, what technology was available that:
>
> 1) was cross-platform,
> 2) allowed bits of information from all over the world to be rendered togeter,
> 3) Included pictures and sound as well as text,
> 4) Did all the above cheaply and reliably.
>
> I don't remember it, either.
I should hope not, because it didn't exist. Refer to my first comment, above.
>> So: having gone from a world of functional, stateful, distributed applications engineered to a true
>> software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to
>> procedural programming and dumb terminals (meaning Web browsers).
> What world are you thinking we came from? I remember when Kermit file transfer was a big advance...
Yes, indeed. These were low-tech applications built from pieces that were suited to the purpose. The original Web, by and large, was also built from suitable components. The problem is that it was too successful. We now have a situation where, in order for any application to gain distribution, it must somehow run in a browser - an object whose original function was simply to display content. What if gopher had been the successful application? Would it make any sense to continually paste more and more pieces onto gopher clients while claiming that it's the One True Way to write networked applications? Or would it make more sense to concede that the model had grown by aggregation, and perhaps it was time to consider other approaches?
>> In other words, 1970s technology with pictures.
> Your car uses a technology that's now provably thousands of years old - the wheel. Do you complain
> about the age of this technology, or do you simply accept that it works?
It's fairly clear that my comment was about function, not age. Web applications lack true interactivity (among many other things), and are, metaphorically, similar to the 1970s model of mainframe computing.
>> Any half-wit can see that this situation is broken.
> Perhaps only half-wits see it this way. How did you post this article again? Oh, yeah, using 70s
> technology! But you did it, didn't you? I read it, I responded. Neat, huh?
Not very. Message servers have existed for decades.
> It's not everyday that you end up with an application that:
>
> 1) Works no matter where you are,
>
> 2) Requires no additional install to work,
>
> 3) works with data from servers around the world,
>
> 4) Delivered in real time, on request,
>
> 5) Using stock, commodity hardware and communications technology.
These comments are about the Web, and as I've said already, I never disputed any of it. If, on the other hand, we're talking about Ajax proper (the subject of my posting), we could add:
6) is hideously complex to implement, to the point where most developme
Thanks.
It's encouraging to know that there are still some sane people out there.
1) The fact that you can keep a connection open and send multiple requests in one message does not make HTTP stateful. In any case, it's fairly obvious that I was making general observations about the evolution of Web technology, not inviting arguments about trivia.
2) I very clearly made no attempt to defend object-oriented technology, and the issue of concurrency has nothing to do with why Ajax is badly designed.
3) I made no assertion about how data should be shared, though your implication that RDBMS can solve all data-sharing problems is rather strange.
4) I made no attempt to defend GUIs, most of which suck.
>> I made no assertion one way or the other about HTML and HTTP being suitable for particular purposes.
.]
.]
>> Eulogize all you want about the wonders of the Web. It has nothing to do with my point.
> Okay, well if it had nothing to do with your point then why even mention that HTTP is a 'lobotomized'
> form of something else?
Quoting myself: "The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place."
> Nice ad hominem attack. That really proves your intelligence.
Gee, I'm sorry. I didn't realize that when you called me a Nazi you meant it in a nice way.
> Um, in case you didn't read your own comment, you said that the web is procedural because dumb data
> is passed to 'stateless' objects.
And your response to this was, "This sentence is complete gibberish. Java is platform independent? Pretty close maybe."
> I explained that this is nonsense because there's nothing stateless about web applications. Yes, HTTP is
> stateless. Therefore web applications implement state at a higher level. [etc.]
Quoting myself (for the third or fourth time now): "The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place."
> But what you didn't explain is why you need to pass objects to the client? Since everything is happening
> on the server [. .
You've answered your own question here.
> The idea that software is not 'real' unless it's a client-server architecture with code being transmitted
> across the network is extremely narrowminded.
Show me where I say this. Getting into a discussion with you about what's real and unreal would obviously be very foolish.
> Honestly, have you ever written a web application? If all your code is object-oriented, how is it that then
> magically it is lobotomized by a transmission protocol and suddenly procedural. There's plenty wrong
> with web development, but I'm afraid you're not getting it.
Again, I believe you've been listening to the voices in your head rather than to me. Can you point out where I say that a transmission protocol makes things procedural? When you say, "you're not getting it," which of us are you speaking to?
> Your problem is you don't seem to think there is any value to keeping your code on your server [. .
Of course there's value to doing this - if that's what is appropriate for my application.
> or distributing your application by means of a URL that anyone can type in to instantly access your
> application
Where did I say this? Quote me, please.
> or tight integration with tons of other applications on the same platform.
Ah, then maybe I don't get it after all. Maybe you could show me the setting that allows me to drag an "object" from my google map onto a message I'm composing in gmail and have the object ask me if I want to include directions from the recipient's house. A theoretical explanation will suffice.
> Or maybe you just think there is a better way of achieving these benefits. Well call me when the better
> solution is out there.
Okay. What's your number? Seriously.
Look, I'm going to be nice for a moment despite all the names you called me. I am not criticizing people who write Web applications. I am not even criticizing (at least not stongly) the Web as it was originally conceived. I am, instead, saying that Ajax (as a technology, not as a way to make a living) is like trying to paste a Chevy Suburban onto a blender in order to produce a space shuttle. It simply violates common sense. Yes, you can make it do certain things, and I expect we'll probably see a lot more of
Yes, I have a grudge against all of the institutional stupidity that drives the technology industry.
1) I made no comment whatsoever about http's reasons for being stateless. If you think it's a "Good Thing," I couldn't care less.
2) If you actually read my posting, you will find that I also said nothing about ajax being stateless. I said that it layers a lot of complicated nonsense on top of the existing Web mess in order to compensate for capabilities that the underlying layers engineered out.
3) "Processing appropriate to the client" does *not* take place on the client in an ajax "application." What takes place on the client is whatever processing the framework allows.
4) Yes, a "real programmer" (as you put it) can make Ajax clients and servers cooperate to some extent. A real programmer can also write a 3-d game in assembly language.
5) If, again, you actually read my posting, you will see that I say nothing about ajax refreshing entire screens. Refer to #2. I agree, however, that someone has missed the whole point.
Independent thinking is not at all easy. I have never known a teenager to do it; on the contrary, teenagers are among the strictest conformers on earth.
Is your point that revolutions are hard, therefore everyone should just conform?
But if you were really making an honest request to see an alternative to Ajax, then fair enough. The fact is that there are many alternatives (once you start considering the problem from its root). If you would like to see one that *really* works, I'd be glad to show you. Unfortunately, I'm not willing to discuss it in this forum.
There's a contact link on my company's Web site: www.ektasis.com. If you send an e-mail through the link, I'll be glad to invite you over for some show and tell.
Oh please - not another true believer saying "Oh please" and pretending to refute an argument by using dramatic words like "tired" to imply that it has already been refuted.
.," etc. is simply wrong). The point is that real software gives you a choice.
1) I made no assertion one way or the other about HTML and HTTP being suitable for particular purposes. Eulogize all you want about the wonders of the Web. It has nothing to do with my point.
2) Yes, Java is "pretty close" (in your own words) to being platform independent. So if my sentence is gibberish, then you are also spouting gibberish. In either case, I used the term "platform independent" simply as an adjective describing Java. Had you been able to hold my entire sentence in your little head at once, you would have seen that my point was about "object oriented" vs. "procedural," not "platform independent" vs. "platform dependent." So again, you are driveling on about irrelevancies.
3) I don't care whether your data structures are XML or PMS. An intelligent reader would have discerned my point: they are *data structures*, not objects. An object can also be just data if you want it to be; in fact, serialized Java objects (as an arbitrary example) *are* just data, in the sense that only the object *state* is serialized (so your rant about "Why pass bloated objects and more code . .
4) My contention is precisely that Ajax attempts to simulate an object-oriented model by layering hideously complicated sets of stuff on top of a pre-existing structure that is not itself object oriented (or, more precisely, used to be object oriented until it was lobotomized). So where you go on about "object orientedness" having "nothing to do with the underlying protocols," I thank you for your support.
5) Yes, we all know that Javascript puts "view" code in the browser. Bully for you. And I apologize for not being sufficiently excited that my Web applications force me to take nearly the entire processing load on my server while the client's 3GHz machine sits idle waiting for a picture to paint. I will try to imitate your macho stoicism by meditating on the fact that my application code has the privilege of staying "in a controlled environment where it is secure." While I do this, I will also try to avoid any unpleasant questions about the security of my browser.
6) You go on quite a bit about Java objects and such. I couldn't care less about Java in particular, but what you say (namely, that Java cannot do "much we can't do just as easily now") is absolutely true (though it's a bit beyond me why it needs stating that Java can't do anything that software can't do). Ajax, on the other hand, is capable of doing considerably less.
7) Yes, HTML is simpler than writing a gui. Perhaps you can explain how this relates to what I said.
8) Regarding dumb terminals, go learn what a metaphor is. I forgive you for not knowing. As you say, "This is pure ignorance."
But honestly. Why pick nits at a time like this. You have provided me with a profound revelation. Your point about "abstraction" has helped me see the light. I realize now that I have been misled all my life concerning the meaning of this word. I always thought it had something to do with encapsulating logic so that people could write more functional applications. I see now (with your help, for which I am deeply grateful) that it's really about encapsulating things so that people can write *less* functional applications. I'm going to sign off now so that I can pan around my google map and reflect on how awe-inspiring it is.
You are so right. I'll stop pining for my compilers immediately and join the herd.
It seems you already have religion, so why do you want a revolution? Or maybe you were reading the wrong posting because mine only implied a wish: that "technology" people stop acting like herd animals and actually fulfill their reputation as independent thinkers. Or is that hype too?
Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.