On Mon, 11 Jul 2011 20:49:01 -0400
Ken Wesson <kwess...@gmail.com> wrote:
> 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.
You write clearly enough that misinterpretation isn't likely. You were
simply making false statements.
> > 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 all you know is "GET /index.html", then you don't know the syntax
of the HTTP GET statement. The terminator - a pair of line endings -
is part of the syntax. If you send that string and the terminator to
an HTTP server, it should send back the contents of index.html.
> > 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.
Sorry, but "GET /index.html" *is* HTTP. Oh, it's not all of it, by any
means - but it's enough to talk to a server. A much closer analogy
would be that SQL is like the URL syntax in the HTTP GET/POST
request. Knowing the URL isn't enough to talk to a web server. You
have to know the wire protocol, or the API for a library that
implements it for you.
> > 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"?
Only if they also stopped listening for requests on something like a
socket. Which was your objection to running a repository: you think it
means you have to have something listening on a socket. This isn't the
case. In particular, it isn't the case for the maven repository that
was being recommended as a solution to the problem.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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
