[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lisp/url/url-https.el
From: |
Simon Josefsson |
Subject: |
Re: lisp/url/url-https.el |
Date: |
Thu, 15 Apr 2004 01:42:27 +0200 |
User-agent: |
Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>> I am willing to work with any standards Emacs has, but there has to be
>> some way to allow a willing user to plug in encryption code easily
>> into Gnus, once that code is downloaded. As it is, and according to
>> what you have told Lars Magne Ingebrigtsen and he has relayed to the
>> Gnus developers, not even empty wrapper functions that could be used
>> for encryption are allowed. That makes my life much harder.
>
> My understanding is that the problems only show up for code that's meant
> specifically for encryption.
> So you should be able to provide hooks as long as they are not specifically
> for encryption.
>
> I know nothing about your specific problem so I'm probably talking
> non-sense, but why should .authinfo and Gnus be so special?
>
> 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).
>
> Or maybe we can even make the patch to jka-compr.el generic enough (allow
> "(de)compression with a program that requires interactive user input")
> to make it acceptable for inclusion in Emacs.
>
> Wait isn't something like that already available?
There is crypt++, but when it was discussed in the context of Gnus, I
think it was decided it was not really good enough, the programmatic
elisp API insufficient, and that we could never get copyright papers
for it anyway. I believe it was suggested to make a generic package
for this. This same problem does indeed occur in many situations. I
thought, but perhaps I have just been secretly wishing it, that Ted
was working on something like that.
- Re: lisp/url/url-https.el, (continued)
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/10
- Re: lisp/url/url-https.el, Kim F. Storm, 2004/04/10
- Re: lisp/url/url-https.el, Richard Stallman, 2004/04/11
- Re: lisp/url/url-https.el, Mario Lang, 2004/04/13
- Re: lisp/url/url-https.el, Richard Stallman, 2004/04/14
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/14
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/14
- Re: lisp/url/url-https.el,
Simon Josefsson <=
- Re: lisp/url/url-https.el, Stefan Monnier, 2004/04/15
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/15
- Re: lisp/url/url-https.el, Richard Stallman, 2004/04/16
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/16
- Re: lisp/url/url-https.el, Simon Josefsson, 2004/04/15
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/15
- Re: lisp/url/url-https.el, Richard Stallman, 2004/04/16
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/16
- Re: lisp/url/url-https.el, Eli Zaretskii, 2004/04/17
- Re: lisp/url/url-https.el, Ted Zlatanov, 2004/04/21