On Mon, Jul 11, 2011 at 7:39 PM, Mike Meyer <m...@mired.org> wrote: > On Mon, 11 Jul 2011 07:51:33 -0400 > Ken Wesson <kwess...@gmail.com> wrote: > >> On Sun, Jul 10, 2011 at 2:01 AM, mike.w.me...@gmail.com <m...@mired.org> >> wrote: >> [snip most of post whose sole purpose seems to be to gainsay anything I >> write] > > Because in that article, you were (unusual for you) way off base.
As you say, it would be unusual for me if that were the case -- good reason to suspect that perhaps I wasn't, but rather was misinterpreted, or something. > SQL doesn't have a position anything like HTTP GET/POST syntax. Sure it does. Queries are bundled into a wire protocol and sent over the network in pretty much every system I've seen that used a database. You have the web server over *here*, and it is visible to the internet because the gateway forwards port 80 to it *here*; it talks over the LAN to the DBMS over *here* to run various queries and build a page to serve ... > HTTP's GET/POST syntax is a wire protocol. HTTP is a wire protocol. The syntax of GET/POST requests is carried on that protocol (as are HTML files and other files sent back to the client) but is not the protocol itself. > Once you it, you can write code to talk to a server, and get a > response. Not if all you know is "GET /index.html". You need to speak HTTP and then send that. > If you know SQL, you can't use a database *at all*. You have > to know an API for the database in question Just as you need to know HTTP and not just "GET /index.html". The difference here is that the databases haven't all settled on one embedding, analogous to HTTP, for the SQL requests, but all the vendors use their own different one. > Last time I looked, there wasn't a standard wire protocol > for SQL servers. Which doesn't change much of anything. There's HTTP 1.0 and HTTP 1.1 for web servers for that matter, though mostly you can ignore the differences and, indeed, these days HTTP 1.0 as a whole. It's not hard to imagine a world where a non-HTTP protocol became a rival to HTTP, either -- for instance, one with built-in support for mirroring of static content instead of having to fudge around with things like Akamai for that, perhaps even one where individual browsers made parts of their caches (not https stuff, though, obviously, or form contents) available automatically as alternative sources to take some of the load off central servers and possibly even maintain some availability when they were down. If that were to happen, would the things that interpret GET requests suddenly stop qualifying for being considered to be "servers"? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
