On Fri, 10 Sep 2010 01:08:06 -0400
John Newman <john...@gmail.com> wrote:
> (use '[clojure.contrib.server-socket :only (create-server)]
> '[clojure.contrib.duck-streams :only (read-lines)])
> (create-server 8080
> (fn [in out] (when-not (empty? (read-lines in)) (spit out "Hello,
> World!\n"))))
>
> 4/0/0
Nah, 4/0/1 - I count the implementation language as a tool in every
case. Unless you forgot the clj script and the #!/usr/bin/env clj
line, so it's 5/0/2.
Believe it or not, on at least one occasion I've put things on that
level into production on the public internet. It met the requirements,
including scalability for any foreseeable growth.
I think that Java's strength is enterprise-level, highly scalable web
servers make people assume that every problem must be a nail for that
hammer. The thing is, out here in the real world, the vast majority of
web-based applications have no need to be highly scalable.
Sure, if you put an app on the public internet, you ought to be
prepared for it to go viral and have a plan for serious
scalability. But most web applications aren't on the public
internet. Look around your own office - or even your own house. How
many lan-only web serves do you have? They're never going to scale
beyond the size of your company. I've got about six such running here
(two for real services, two for development, and two for doing test
builds on the deployment platform). And calibre, which runs a web
server to transfer ebooks from my library to ebook readers. If you
count the not-http-apache modules I'm working on, and the servers that
speak that protocol, that adds another half dozen. Apps running on
those don't need to be highly scalable, so why should someone
deploying to them have to deal with such cruft? Now look for any kind
of network appliance: routers, printers, NAS boxes, who knows what
else. Chances are they have a web server embedded in them
somewhere. There's no good reason for them to need to deal with two
simultaneous connection, but most use an open source server that's a
bit better than that. I've got at least five of those on my LAN, and
I'd be surprised if the cable modem doesn't run one. They only way
they'll get the kind of traffic that would require scalability is if
someone DDoS's them. Further, they tend to run on boxes with very
limited resources, so not only do they not need the overhead for
scalability, but providing it is liable to make a noticeable impact on
system performance elsewhere. Finally, for a real kicker, up through
iPhone OS 3, Apple failed to provide a standard method to move data
between the iPhone and desktop applications. So applications that
wanted to do that tended to run a web server for the purpose (except
for one oddball app that ran an ftp server). I had three or four of
those before I switched to Android. Since Android lets apps write to
disk that can be mounted via USB on your desktop, most do that - but I
wouldn't be surprised if there was at least one web server lurking in
the system somewhere. Even more limited resources, and slower CPUs
thanks to the battery issues. And before you complain that Java's not
appropriate for that environment, consider Java ME and Dalvik.
Nah, web servers that simply don't need to be scalable far out number
those that do. The only question is whether the curve is a bell curve
or an inverse logarithm, but in either case things that need to be
"highly scalable web servers" are out under the tail of the curve.
The fast majority of web servers don't need that, they just need a
simple way to get the code running. Which is why "simple things
should be simple" is important - there are a lot more of them than
there are of the others.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce 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
