Re: GnuTLS for W32

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 03 Jan 2012 02:14:19 -0500 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Mon, 02 Jan 2012 17:35:21 -0500
>> 
EZ> It makes sense, but how is ELPA easier than any other download
EZ> address?  All that's needed is to download a single zip archive and
EZ> unzip it.  Why does it matter if it comes from ELPA or from
EZ> elsewhere?
>> 
>> ELPA updates can be done entirely from within Emacs.

EZ> See below: currently, using this for anything not Lisp-based, like
EZ> installing a new dynamic library, is a pipe dream.  (Actually, even
EZ> downloading a new version of a Lisp library into a running session has
EZ> its problems, as discussed here recently; but I digress.)

You're taking current technical limitations and applying them to a UI
comparison.  The package.el UI is far superior to a download+unzip
process, especially if that process needs to happen more than once and
for more than one package.

>> Downloading and unzipping a file is a nuisance.  Imagine if you
>> asked GNU/Linux users to do the same.  "But they have package
>> managers..."  Exactly!  And so does Emacs, now that package.el is
>> here!

EZ> And I thought only Windows users were spoiled enough to demand
EZ> one-click installations.  "Downloading and unzipping is a
EZ> nuisance"... sheesh.

It's 2012.  Emacs must be compared with Firefox and Chrome, not with
vi/vim.

If you don't see how passing the download+unzip burden to the user is a
nuisance to them and consider it "spoiling," I think that's unfortunate.

>> Can Emacs modify the DLL search path on W32 so it can install some DLL
>> from ELPA and then activate it dynamically?  Or does it require a
>> restart and modifying the global PATH?  Either way, can the process be
>> automated?

EZ> We currently lack infrastructure to replace a DLL that is already used
EZ> by a running Emacs process.  The code that loads a DLL and initializes
EZ> the function pointers used to access its APIs assumes this will be
EZ> done only once in a given session, so currently we do need a restart.

EZ> To be able to replace a DLL without restarting Emacs, we would need to
EZ> add code to free and unload a used DLL from the Emacs process, and
EZ> then load the new one.  This might be complicate if there are data
EZ> structures lying around that use the DLL facilities, like an existing
EZ> connection using GnuTLS or an image displayed using an image DLL.  We
EZ> will need to shut down the relevant Emacs features before replacing
EZ> the DLL.

EZ> There will also be complications with this if another Emacs process
EZ> runs the same binary and uses the same DLL, because I don't think you
EZ> can overwrite the DLL from under the feet of that other process.

EZ> If you are thinking about a limited goal of installing for the first
EZ> time a DLL that does not yet exist and is not loaded into Emacs, then
EZ> it can be done, although some code will need to be written for that as
EZ> well, and I'm not sure package.el is designed to handle such
EZ> "packages".  Moreover, I'm not sure such a limited goal would be in
EZ> the spirit of package managing, since upgrading an installed package
EZ> is an important part of that, perhaps more important than the initial
EZ> installation.

OK, so let's do a restart after a DLL package install or upgrade.  It's
better than nothing.  Can this process be reused for other DLLs like the
libxpm DLL?  Can we activate the new DLL after Emacs restarts, so the
old one will remain active as long as Emacs is using it and the user is
not forced to restart immediately?

I'm not sure if multiple Emacs processes are an important use case.  I
would guess it's an edge case on W32 and can probably be handled by
scanning the process table and insisting that all Emacs instances be
shut down.

JB> But anyway, the issue is not just monitoring. Someone has to build
JB> updated binary GnuTLS packages for Windows. That Eli just did it does
JB> not mean we can burden him with the task forever.
>> 
>> We can automate that.

EZ> Who exactly are "we" in this sentence?

emacs-devel; at least me specifically.

>> Eli and Nicos have done the hard part, I think.

EZ> I did nothing of the kind.  I just configured and built the stock
EZ> distribution, and fought whatever problems I found that prevented the
EZ> build and the test suite to run to completion.  The record of that
EZ> fight includes 18 "issues" which I will be reporting to GnuTLS
EZ> developers soon; until those are resolved, the build I did is anything
EZ> but an automatic thing.  And I don't see how anyone else's build can
EZ> be fully automated, unless the "issues" I bumped into are due to my
EZ> own misunderstandings.

EZ> In any case, my experience indicates that having a steady feed of
EZ> regular updates of Windows builds of any non-trivial package can never
EZ> be based on a single individual, no matter if his/her name is Eli,
EZ> Nicos, or something else.  People invest in this some time for as long
EZ> as they have it or are interested, and then go away to pursue other
EZ> interests or go on with their lives.  You cannot build a reliable
EZ> infrastructure on something that is not part of your project.

I'm not sure what you and Juanma want to say.  That because we don't
have salaried positions for tracking GnuTLS updates to Emacs, it's a
burden?  Or that we shouldn't even do it?  Or that we need more people
to run the Emacs infrastructure?  What's the problem and how can we
solve it?

EZ> Bottom line, I feel that letting users download and unzip DLLs is by
EZ> far more practical for this purpose than what you suggest.  It also
EZ> has the advantage of already working.

It certainly is easier for us, the developers.  But I think it's not the
best solution we can offer to the users.

Ted