Re: Web services 101

>> Hope you won't think it immodest, but I'd suggest my web app tutorial.

>Good reading stuff.  As we've seen many people struggling how to get
started and what is around, I've compiled a FAQ entry.  It became more
like a whitepaper, so at some point we may decide to add a whitepaper
entry to the website (what do you think, Anne?). 

I've run into several people recently who struggled with the running as a daemon method,
and I never use it myself. Instead I normally run LAP stack (Linux-Apache-Prolog),
running the prolog server on a high port and forwarding with an Apache rewrite directive.

This has several advantages:
   * It's more accessible to programmers with the average web programmer's skill set. It smells
less of voodoo. 
   * Allows access to the great masses of software written in some other language. Even the SWI-Prolog web site demonstrates this - there was absolutely no reason to write yet another bug tracker, and you wisely didn't - bugzilla does it's job just fine.
   * As you note in 'disadvantages', being the web server means accepting responsibility for a host of issues like DDoS defence, load balancing, overload regulation, monitoring, and so on. Apache handles these just fine. 

Other comment I'd make is that many people visiting this page are actually asking the question
"how do you replace a LAMP infrastructure?". I think a link to my tutorial should be up near the top.

On the subject of my tutorial, I've been assuming that as soon as our little crew of website gnomes get there we'll be moving the web tutorial off pathways and into standard wiki format and putting it on SWI-Prolog.org under tutorials->intermediate->web application.  Unfortunately one of your gnomes (the smiley one) is off building a game, and after that needs to do things for other employer that she's ignored during game building.

As for 'lack of masses of Prolog programmers you can hire' - based on watching Runa be first adopter of Clojure, I'd say this is an advantage rather than a disadvantage for first adopters.
Bluntly, in any group of programmers you've got some who are immensely smart and some not so. Whoever first builds their infrastructure on a cutting edge platform gets to hire the immensely
smart ones.

Also, in economic terms, the 'price' of programming talent is dependent on relative supply/demand.
At the moment there's supply, but nearly zero demand. If I weren't working in odd corners where I
get to pick my technology stack I'd never be able to work in Prolog (indeed, the AI/Robotics work I'm doing isn't in Prolog for the most part. The one thing I did in prolog is the odd duck in the system).

Admittedly, at the moment the supply of programmers who are actually skilled in making real world applications is limited. But I think that could change rapidly. Anyone on this channel who'se here because they're a language hobbyist probably already has a day job making web applications. Any of them could pretty much read my web apps tutorial, spend a while fiddling with a few library modules like settings, and be pretty competent.

One advantage of Prolog you don't mention in your LP Framework page is how unification makes API sizes shrink.  Parameter validation is *one* API point! Real world programmers spend most of their
time NOT worrying about algorithms, but rather making bits of other people's technology work together. Most of us are professional learners. And the 'little DSLs everywhere' nature of
SWI-Prolog, esp. when the little DSL is an option list, greatly reduces the code footprint
we have to learn.

I suspect you may overestimate how large an organization is needed for 'running a critical application'. The web is changing. The humongous web company with thousands of employees and
a well recognized name is not the normal case - it's just the one we hear about. 

Our first adopters will be hobbyists and people with unusual needs (which probably means academia
and/or people like me who tend to make lots of 'odd' web applications [eg me making
an HTML5 mobile game, Wouter making research software]. Following closely behind will be early
adopters in one-programmer shows who just like the language [me building websites for a fixed size
audience for Univ. of Houston,  RLa building a CMS largely for fun].
Clojure's first applications were mostly things like internal tools. For a while the Clojure meetups at Runa were punctuated by stories of people who had introduced Clojure at their day job
by writing a tool in it.

"Another problem is the (un)availability of server-side plugins to access external APIs."
Instead of this, why don't you say we inter operate well with Java and C?

A weakness we should address is that many commercial users do indeed need to talk to legacy relational databases. The ODBC driver connection documentation is sketchy at best. After struggling
to set it up, I eventually resorted to doing something slightly crazy - shelling out and
using mysql's command line to do my work (which fortunately was very low volume).

OK, and I gotta put in this dig - if strings are wrong, what happened with double quotes in 7?