imgur.el and small packages to interface with commercial services

imgur.el and small packages to interface with commercial services

[Lars Magne Ingebrigtsen]

There's a lot of "glue packages" for Emacs that interface with some
proprietary service or other.  I've just written one for imgur (for
uploading images on the web), which is something that I've wanted to
have for years, but never got around to writing:

https://lars.ingebrigtsen.no/2016/06/29/emacs-imgur-interface/

Are these things inappropriate for GNU ELPA?  I'm guessing that they
would be, so perhaps Marmalade is the place for stuff like this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Not considering GNU Elpa, Melpa is the most used repository. I haven't seen
anything that's on Marmalade but not on Melpa.

On Wed, Jun 29, 2016, 8:21 AM Lars Magne Ingebrigtsen <larsi@gnus.org>
wrote:

> There's a lot of "glue packages" for Emacs that interface with some
> proprietary service or other.  I've just written one for imgur (for
> uploading images on the web), which is something that I've wanted to
> have for years, but never got around to writing:
>
> https://lars.ingebrigtsen.no/2016/06/29/emacs-imgur-interface/
>
> Are these things inappropriate for GNU ELPA?  I'm guessing that they
> would be, so perhaps Marmalade is the place for stuff like this?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>
>
> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1414 bytes --]

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

[Ted Zlatanov]

On Wed, 29 Jun 2016 14:21:15 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> There's a lot of "glue packages" for Emacs that interface with some
LMI> proprietary service or other.  I've just written one for imgur (for
LMI> uploading images on the web), which is something that I've wanted to
LMI> have for years, but never got around to writing:

LMI> https://lars.ingebrigtsen.no/2016/06/29/emacs-imgur-interface/

LMI> Are these things inappropriate for GNU ELPA?  I'm guessing that they
LMI> would be, so perhaps Marmalade is the place for stuff like this?

Maybe if it was a more generic image uploading package? No need to limit
to just imgur, there's a million of these services.

Ted

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

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 29 Jun 2016 14:21:15 +0200 Lars Magne Ingebrigtsen
> <larsi@gnus.org> wrote:
>
> LMI> There's a lot of "glue packages" for Emacs that interface with some
> LMI> proprietary service or other.  I've just written one for imgur (for
> LMI> uploading images on the web), which is something that I've wanted to
> LMI> have for years, but never got around to writing:
>
> LMI> https://lars.ingebrigtsen.no/2016/06/29/emacs-imgur-interface/
>
> LMI> Are these things inappropriate for GNU ELPA?  I'm guessing that they
> LMI> would be, so perhaps Marmalade is the place for stuff like this?
>
> Maybe if it was a more generic image uploading package? No need to limit
> to just imgur, there's a million of these services.

Yes, and they all have their own proprietary APIs...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ted Zlatanov]

On Thu, 30 Jun 2016 17:39:32 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Maybe if it was a more generic image uploading package? No need to limit
>> to just imgur, there's a million of these services.

LMI> Yes, and they all have their own proprietary APIs...

Obviously, otherwise there would be no value added :)

Ted

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Maybe if it was a more generic image uploading package?

The more general it is, the better -- but we don't have to reject
a package for one single site, if that site is well known as imgur is.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   I've just written one for imgur (for
  > uploading images on the web), which is something that I've wanted to
  > have for years, but never got around to writing:

  > https://lars.ingebrigtsen.no/2016/06/29/emacs-imgur-interface/

  > Are these things inappropriate for GNU ELPA?

Off hand, I see nothing wrong with them.
Does anyone want to propose arguments for rejecting them?

I'll consider whatever arguments people present, but as
of now I think we want to accept these in GNU ELPA.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Ted Zlatanov]

On Thu, 30 Jun 2016 13:57:19 -0400 Richard Stallman <rms@gnu.org> wrote: 

>> https://lars.ingebrigtsen.no/2016/06/29/emacs-imgur-interface/

>> Are these things inappropriate for GNU ELPA?

RS> I'll consider whatever arguments people present, but as
RS> of now I think we want to accept these in GNU ELPA.

As I was saying, I think the package name and call interface should not
contain "imgur" but rather that should be a symbol meaningful to the
package. So instead of:

    (defun imgur-upload-image (image &optional datap)  
    "Upload IMAGE to imgur and return the resulting imgur URL. [...]

We'd have:

    (defun larsuploader-upload-image (image service &optional datap)  
    "Upload IMAGE to SERVICE and return the resulting URL. [...]

...which can then support Imgur and the *hundreds* of others out there.

Testing that package will be a huge pain.

Ted

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As I was saying, I think the package name and call interface should not
  > contain "imgur" but rather that should be a symbol meaningful to the
  > package. So instead of:

  >     (defun imgur-upload-image (image &optional datap)  
  >     "Upload IMAGE to imgur and return the resulting imgur URL. [...]

  > We'd have:

  >     (defun larsuploader-upload-image (image service &optional datap)  
  >     "Upload IMAGE to SERVICE and return the resulting URL. [...]

I think the first name is better, because it relates to the job the
program does, so users will remember it.  "larsuploader" has nothing
to do with the job, so it is an arbitrary obstacle to memory.  I can't
see that it does any good.

  > ...which can then support Imgur and the *hundreds* of others out there.

Each site will be different, so there is no benefit in implementing
them together.

We could provide an overall interface called 'upload-image'
which would ask you which site and then call its uploader.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Ted Zlatanov]

On Fri, 01 Jul 2016 18:03:38 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> Each site will be different, so there is no benefit in implementing
RS> them together.

I disagree. The APIs are very similar among them. Do we want a package
for every such service?

RS> We could provide an overall interface called 'upload-image'
RS> which would ask you which site and then call its uploader.

That's exactly what I proposed. The `larsuploader' part was supposed to
be funny.

Ted

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > RS> Each site will be different, so there is no benefit in implementing
  > RS> them together.

  > I disagree. The APIs are very similar among them. Do we want a package
  > for every such service?

If it's feasible to support multiple sites with the same code, I
have nothing against it.



-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Ted Zlatanov]

On Sat, 02 Jul 2016 20:06:31 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> Each site will be different, so there is no benefit in implementing
RS> them together.

>> I disagree. The APIs are very similar among them. Do we want a package
>> for every such service?

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.

Ted

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

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 02 Jul 2016 20:06:31 -0400 Richard Stallman <rms@gnu.org> wrote: 
>
> RS> Each site will be different, so there is no benefit in implementing
> RS> them together.
>
>>> I disagree. The APIs are very similar among them. Do we want a package
>>> for every such service?
>
> 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.

Yes, having a general "upload image" package would be very nice.
However, they all seem to rely on access keys (and the like).  For
instance, imgur.el comes with a token that's connected to my account
(but images are uploaded as "public", so they're not tied to me once
they're uploaded).

And that feels kinda odd for a general package, but might be acceptable
for a specific package.

Ideally the distributed access key would be registered to the FSF or
GNU, but I'm not sure anybody would be interested...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ted Zlatanov]

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

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

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I suggest making the token automatic, stored in auth-source and
> generated on demand (so it will be local to the user).

That is generally not possible.  To get an imgur token you have to
register yourself on their web site and exchange some emails, and then
you get a token.

> 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.

It doesn't really matter that much.  imgur rate-limits per IP address,
not per token.

Other services probably have other rules.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ted Zlatanov]

On Wed, 20 Jul 2016 15:16:37 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I suggest making the token automatic, stored in auth-source and
>> generated on demand (so it will be local to the user).

LI> That is generally not possible.  To get an imgur token you have to
LI> register yourself on their web site and exchange some emails, and then
LI> you get a token.

Right, so you can offer your imgur token as a default choice at the
prompt, and if the user wants, they can use their own. The choice is
stored locally and they can edit or remove it later. Is that acceptable?

>> 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.

LI> It doesn't really matter that much.  imgur rate-limits per IP address,
LI> not per token.

LI> Other services probably have other rules.  :-)

OK, so it should be a flexible choice...

Ted

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

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Right, so you can offer your imgur token as a default choice at the
> prompt, and if the user wants, they can use their own. The choice is
> stored locally and they can edit or remove it later. Is that acceptable?

Well, prompting when no prompt is necessary seems less than optimal, but
they can just change `imgur-client-id' if they care...

Or the equivalent in a package that handles many services.

I'm a great believer in not making users customise anything if that can
be avoided.  Software should just work.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ted Zlatanov]

On Wed, 20 Jul 2016 15:46:29 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Right, so you can offer your imgur token as a default choice at the
>> prompt, and if the user wants, they can use their own. The choice is
>> stored locally and they can edit or remove it later. Is that acceptable?

LI> Well, prompting when no prompt is necessary seems less than optimal, but
LI> they can just change `imgur-client-id' if they care...

LI> Or the equivalent in a package that handles many services.

LI> I'm a great believer in not making users customise anything if that can
LI> be avoided.  Software should just work.  :-)

OK.

So customize `image-upload-imgur-client-id' then... works for me.

Ted

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

[Stefan Monnier]

> I'm a great believer in not making users customise anything if that can
> be avoided.  Software should just work.  :-)

I was about to send a silly comment about you being lazy and everything,
and then I realized as I wrote it that really, this "software should
just work" attitude basically implies as a consequence "no security and
no privacy".

E.g. "I shouldn't have to type in some password to use my computer.
It should just work".


        Stefan "who also likes things to just work, tho"

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I was about to send a silly comment about you being lazy and everything,
> and then I realized as I wrote it that really, this "software should
> just work" attitude basically implies as a consequence "no security and
> no privacy".

I'm sorry, but I fail to see the relevance between what you're saying
here to the issue of imgur public image uploading.

You'll have to explain what you mean, I'm afraid.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no