Re: lisp/url/url-https.el

[Ted Zlatanov]

On 16 Apr 2004, address@hidden wrote:

>>> Can't we write a generic "auto-decrypt-mode" which works similarly
>>> to auto-compress-mode (or maybe even a patch to auto-compress-mode
>>> which allows "compression using gpg") ?  This package wouldn't be
>>> distributable with Emacs but it doesn't have anything specific to
>>> do with Gnus and can distributed separately (e.g. from a non-US
>>> location).
> 
>> crypt++.el does that.
> 
> No, it doesn't.  auto-compress-mode uses file-name-handler-alist,
> whereas crypt++ uses things like find-file-hooks.

Sorry, I didn't know.

>> I find it intrusive, not to mention that it doesn't play nice with
>> many packages (noted as bugs in the comments of crypt++.el).
> 
> Using file-name-handler-alist would make it much less intrusive and
> much more reliable (but would require crypted files to have an
> easily recognizable name).

I think piggybacking on top of Tramp would be best, since it does so
much of the work already.

>> I feel that, because of the complexity and variety of encryption
>> programs and ciphers, a file encryption API is better than the
>> crypt++.el approach.
> 
> I agree that the implementation technique used by crypt++ is
> inappropriate (seems to be inherited from way back, probably a time
> when file-name-handlers-alist wasn't available).
> 
> But could you explain what a file encryption API would provide that
> can't be obtained directly from file-name-handlers?

Well, a file encryption API can always provide the file handlers.  The
file handlers can't provide the API as easily.  An API lets a
programmer control every aspect of our operation; file handlers are a
semi-automatic layer that's just not as useful to developers.

Ted