Re: sqlite3

[Eli Zaretskii]

> From: Madhu <enometh@meer.net>
> Date: Thu, 16 Dec 2021 15:18:30 +0530
> 
> I didn't like situation with json. There is lisp/json.el (in elisp) and
> there is src/json.c which is incompatible.  In a world of ideal emacs
> design (like a decade or two ago) I'd have been able to use the
> interface which emacs provides and switch the implementation, (say if
> the C version was not available).

I think the idea was that no one will want to stay with json.el
because its performance in important applications is abysmally
inadequate.  So investing efforts in making json.el compatible was
deemed a waste of resources.

> the network interface was another example.  When Emacs is not compiled
> without gnutls it was possible to use openssl s_client to get a network
> interface and get the job done.  (This has been obsoleted and requires
> work before it can work) - and emacs user is now constrained to either
> use gnutls or live without ssl, and this is a social-engineering not an
> engineering decision.

IMNSHO, the solution of using starttls external program for SSL
connections was a terrible design (have an external program deliver
signals to Emacs to communicate with it? really?), and I think its
deprecation had this as one of its main reasons.  The other reason was
portability.

Is availability of GnuTLS really a problem nowadays?  I'd be surprised
if it was a problem of any significance.

> And this loss of freedom is implemented in a subtle way, (by the sort of
> arguments which have been presented upthread which invoked gnutls)

The basic argument in the sub-thread to which you responded was that
we add dependencies to Emacs without a good reason, and that
alternative solutions could be available to cover the same needs.  I
think the two examples you provided do not provide justification for
that argument, as valid technical reasons led us to do what we did in
both cases.  If you perceive the results of those technical decisions
as "loss of freedom", then I guess I'll have to disagree.