Re: Web services 101

On 02/09/2014 08:43 PM, Anne Ogborn wrote:
>
>>> 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.

Sysadmins are used to server management scripts. The alternative
requires some other server management system or auto-started sessions
using screen and/or VNC. Nice for developers, not so nice for production
systems.

> * 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.

Running as a daemon doesn't stop any of this.

> * 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.

That is true. You can still use a high port for the daemon based server
and place Apache in front of it. That said, most of our severs run in
auto-started VNC sessions. Quite neat for experimental servers.

> 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.

Find a place and edit the wiki :-) I didn't really find a place. Note
that the tutorial is about _how to use it_. This article is about what is
there, so if you have some plan in your mind (such as Alan), you can
decide whether or not it may work for you.

> 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.

Hmmm. I don't really have a clear picture here. I guess you refer to
http_parameters/2? I can hardly imagine we have the most clever solution
here. Example?

> 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.

Probably true. Still, to run a 24x7 application that is vital to some
organization, you need a team making sure the hardware remains running
(can use the cloud for that), you need access to someone who can fixes
issues and implement changes when needed. You also need to be able to
find a second person in case the first is somehow not available. Of
course, contradictory what is generally believed, natural persons are
much more reliable than organizations :-)

> 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.

There are several users running this stuff for real applications. Most
of them stay silent about it though :-(

> "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?

We operate really well with C/C++, but most of this stuff is not written
in C/C++. We don't operate too well with Java. Installation and
deployment of Prolog and Java is often nasty. The threading models do
not like each other too much and this gets in particular nasty on highly
concurrent web servers. You can have another web server serving part of
the tree.  The SWI-Prolog website provides a CGI bridge.  That should
be moved to the standard library.  That allows running PHP and Perl
scripts.  The performance is not brilliant though.

> 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).

The documentation may be sketchy. The driver is being used for serious
production stuff though and should be considered comprehensive as well
as robust. Most of the trouble managing it is setting up ODBC. Once you
have that and you have configured a DSN, the Prolog part is trivial.

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

As Richard points out, strings are wrong if we use them to analise or
construct text that is subject to some (formal) grammar. I.e., the
string has a well defined meaning that we should grasp by parsing it and
inspecting the resulting tree or, if we need to construct the string, we
create a tree and serialize it according to the grammar.  That is the
difference between

	html(p(Text))
and
	html = "<p>"+Text+"</p>";

The first works, even if text contains <script type="text/javascript">
...</script>.  The second just hopes that Text is well formed HTML text
that can be embedded inside a <p>.

That is also the difference between calling the html parser and doing

       xpath(DOM, //a(@href=HREF), HREF)

to find all links in the page rather than hoping that a regex like
below will do the job (it won't).

       <a\s+[^>]*href="([^"]+)"

Still, you need to represent text in your program and you need to be
able to receive text from other applications and send it back to them.
That must be represented somewhere. Using strings is what other
languages do. Prolog only has atoms (with limits and expensive) and
lists (expensive and ambiguous unless wrapped into a term, but then you
loose the ability to use phrase and list operations on them). Just, as
every other languages, strings should just be passed around, parsed into
trees and created from trees. They should typically not be searched,
split, joined ...  That said, some people want regular expressions :-(

	Cheers --- Jan