From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: imgur.el and small packages to interface with commercial services
Date: Wed, 20 Jul 2016 09:13:30 -0400 [thread overview]
Message-ID: <8760s0bgg5.fsf@lifelogs.com> (raw)
In-Reply-To: m337n47cci.fsf@gnus.org
On Wed, 20 Jul 2016 13:55:41 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Sat, 02 Jul 2016 20:06:31 -0400 Richard Stallman <rms@gnu.org> wrote:
>>
RS> If it's feasible to support multiple sites with the same code, I
RS> have nothing against it.
>>
>> OK. Lars? Would you consider a patch? Or do you want me to package it up
>> and maintain it? Either way, the name change is your choice, I'm just
>> proposing that it shouldn't be a reference to a specific commercial
>> service.
LI> Yes, having a general "upload image" package would be very nice.
LI> However, they all seem to rely on access keys (and the like). For
LI> instance, imgur.el comes with a token that's connected to my account
LI> (but images are uploaded as "public", so they're not tied to me once
LI> they're uploaded).
LI> And that feels kinda odd for a general package, but might be acceptable
LI> for a specific package.
LI> Ideally the distributed access key would be registered to the FSF or
LI> GNU, but I'm not sure anybody would be interested...
Well, whether you make a specialized or a generic package, the tokens
need to be supplied somehow. I think you shouldn't supply your own
unless the upload site agrees to that, and even then maybe it should be
just a one-time choice (the user may not want to use your API token).
I suggest making the token automatic, stored in auth-source and
generated on demand (so it will be local to the user). The auth-source
code supports that case, except for the actual token generation. The
default choice can be a generic token for each service, but I doubt the
FSF/GNU team wants to maintain such a thing, and it would be easy to
abuse it.
Ted
next prev parent reply other threads:[~2016-07-20 13:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-29 12:21 imgur.el and small packages to interface with commercial services Lars Magne Ingebrigtsen
2016-06-29 12:38 ` Kaushal Modi
2016-06-30 15:06 ` Ted Zlatanov
2016-06-30 15:39 ` Lars Magne Ingebrigtsen
2016-06-30 16:05 ` Ted Zlatanov
2016-06-30 23:20 ` Richard Stallman
2016-06-30 17:57 ` Richard Stallman
2016-06-30 18:29 ` Ted Zlatanov
2016-07-01 22:03 ` Richard Stallman
2016-07-02 0:12 ` Ted Zlatanov
2016-07-03 0:06 ` Richard Stallman
2016-07-05 2:34 ` Ted Zlatanov
2016-07-20 11:55 ` Lars Ingebrigtsen
2016-07-20 13:13 ` Ted Zlatanov [this message]
2016-07-20 13:16 ` Lars Ingebrigtsen
2016-07-20 13:30 ` Ted Zlatanov
2016-07-20 13:46 ` Lars Ingebrigtsen
2016-07-20 15:15 ` Ted Zlatanov
2016-07-20 16:41 ` [OFFTOPIC] " Stefan Monnier
2016-07-20 17:01 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8760s0bgg5.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).