[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lisp/url/url-https.el
From: |
Ted Zlatanov |
Subject: |
Re: lisp/url/url-https.el |
Date: |
Sat, 17 Apr 2004 02:18:59 -0400 |
User-agent: |
Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) |
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
- Re: lisp/url/url-https.el, (continued)
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/16
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/17
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/17
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/17
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/21
- Re: lisp/url/url-https.el, Richard Stallman, 2004/04/17
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/16
- Re: lisp/url/url-https.el,
Ted Zlatanov <=
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/17
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/17
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/19
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/19
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/19
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/19
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/19
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/20
- Re: lisp/url/url-https.el, Michael Albinus, 2004/04/20
- Re: lisp/url/url-https.el, Kai Grossjohann, 2004/04/20