emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: imgur.el and small packages to interface with commercial services


From: Ted Zlatanov
Subject: Re: imgur.el and small packages to interface with commercial services
Date: Wed, 20 Jul 2016 09:13:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

On Wed, 20 Jul 2016 13:55:41 +0200 Lars Ingebrigtsen <address@hidden> wrote: 

LI> Ted Zlatanov <address@hidden> writes:
>> On Sat, 02 Jul 2016 20:06:31 -0400 Richard Stallman <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]