Re: DESCRIBE, impnotes, and https client

[<don...@is...>]

Bruno Haible writes:
 > We have three problems. Here's what I plan to do about them.
 > 
 > 1) The DESCRIBE function makes accesses to https://clisp.org/. This
 >    has drawbacks:
 >    - The user cannot do DESCRIBE when an internet connection is not
 >      available.

He can, but currently gets an error - perhaps that should be caught.

 >    - The documentation that the user accesses does not match the version
 >      of clisp she is using.

That could be fixed just by including the version in the url and
keeping multiple versions on the server.

 >    - https access is currently not implemented in clisp.
(discussed below)

 >    - It violates the user's privacy if other parties can infer by sniffing
 >      what documentation she is accessing.

I don't think describe should be accessing the net without 
the user explicitly asking it to, and if the user does choose to
then he can also choose whether to use http or https.

 >    Proposed solution:
 >    Let clisp use the *installed* documentation (packaged with clisp).

I don't see why it is necessary for describe to show documentation
that is not part of the run time environment.
You could supply extra functions for looking up doc and possibly
even mention them in describe output, for instance if you're 
describing an external symbol in ext or lisp packages.

 >    => No network accesses in this case.
 >    For "make check" to work before clisp is installed, add a command-line
 >    option that specifies the location of the doc. (Like option '-N'.)
 > 
 > 2) https access is currently not implemented in clisp. But the web consists
 >    of more and more https.
 >    For https, one needs SSL support with all its intricacies (TLS protocol
 >    versions, certificate checking etc.).

I've used stunnel to solve this problem for a long time.
It seems perfectly adequate and also reasonable.
I don't know whether it's supported on all clisp platforms.

There are millions of things that you MIGHT want to do that are
not built into clisp.  (Some of them are even not built into java.)
I don't see anything wrong with using some external software to do 
them from clisp.

 >    I'm no longer in favour of including something like Drakma in clisp.
 >    Instead, I believe we need to distinguish the bottom layer (SSL) and the
 >    layer sitting on top of it (https). Given SSL, https can well be done in
 >    Lisp. However, the SSL support ought to use a system-wide standard facility
 >    and the system-wide certificates (/usr/share/ca-certificates/mozilla/ on
 >    some systems) - otherwise revocations won't be handled right. This leaves us
 >    with three options:
 >      - GNUTLS,
 >      - openssl,
 >      - CL+SSL, which is based on openssl.
 > 
 >    I'll go with GNUTLS in the first place, and openssl as fallback (for
 >    portability).
 > 
 >    Since SSL cannot be applied to random streams, pipe streams, etc., but
 >    only to socket streams, the result will be a variant of SOCKET-STREAMs
 >    in clisp.
 > 
 > 3) The DESCRIBE function makes accesses to the CLHS on the web. This has 
 >    drawbacks:
 >    - The user cannot do DESCRIBE when an internet connection is not
 >      available.
 >    - It violates the user's privacy if other parties can infer by sniffing
 >      what documentation she is accessing.
 > 
 >    Proposed solution:
 >    Add a facility through which the user can download and install the
 >    complete CLHS on their system once; this requires acknowledging a license.
 >    Cf. [1]

Actually I do like that idea.
I've long kept local copies of both clhs and impnotes to view while
developing lisp code.
I've always viewed them in browsers, though, not emacs.

 >   Bruno
 > 
 > [1] https://stackoverflow.com/questions/23676164/viewing-the-common-lisp-hyperspec-offline-via-emacs