Nim: Remove cookies module from stdlib

Created on 11 May 2018  Â·  17Comments  Â·  Source: nim-lang/Nim

This module really shouldn't be in the stdlib in the first place IMO

Won't fix

Most helpful comment

Fine go ahead, it's not that important, but I consider it a mistake. Python has https://docs.python.org/2/library/cookie.html fwiw. On a related note, these security concerns regarding the JavaScript package management ecosystem made me change my mind, I am now more in favour of a "batteries included stdlib".

All 17 comments

Huh? What is wrong with it?

It's 77 loc and doesn't belong in the stdlib. It's trivial to implement in web frameworks.

I like it though and other web related stuff is also in the stdlib. Seems arbitrary, why does this tiny module that causes no harm nuked?

Because the web moves fast and this module is currently outdated. Instead of creating a PR to a compiler repo it was far easier to adopt it into my project. I believe it should therefore be removed.

Jester is not the only web framework, though. The cookies module may turn out ot be useful in other situations (I am no using it in Rosencrantz, but it can still be used with it)

It's a tiny module and I don't see why it should be in the stdlib when it's
so trivial and often necessary to implement it in the relevant web
framework.

On Wed, 20 Jun 2018, 13:16 Andrea Ferretti, notifications@github.com
wrote:

Jester is not the only web framework, though. The cookies module may turn
out ot be useful in other situations (I am no using it in Rosencrantz, but
it can still be used with it)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/nim-lang/Nim/issues/7810#issuecomment-398728125, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPDe37svkXNHRb6gk7VU6djeyQR0Ui4ks5t-j0agaJpZM4T7QuC
.

Fine go ahead, it's not that important, but I consider it a mistake. Python has https://docs.python.org/2/library/cookie.html fwiw. On a related note, these security concerns regarding the JavaScript package management ecosystem made me change my mind, I am now more in favour of a "batteries included stdlib".

@dom96 what did change in the cookie specification?

Cookies are timeless. As long as there are websites there will be cookies. If it was more complex to implement then it belongs in nimble. But I think there's a saying that simple things belong in the stdlib.

What is the consensus on this one?

Should it be part of the stdlib or moved to graveyard?

Move it to graveyard, dom96 said it's outdated.

I am not sure what outdated means, and @dom96 did not explain. As far as I know, cookies spec has not changed in ages

Here is a very recent addition to cookies:
https://caniuse.com/#feat=same-site-cookie-attribute

On Wed, 17 Oct 2018 at 14:37, Andrea Ferretti notifications@github.com
wrote:

I am not sure what outdated means, and @dom96 https://github.com/dom96
did not explain. As far as I know, cookies spec has not changed in ages

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nim-lang/Nim/issues/7810#issuecomment-430654582, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPDewAgzZ_zbZN24dFu7fXdaLLwbC8Fks5ul0CegaJpZM4T7QuC
.

That is a draft which is not even in any RFC yet. The relevant RFC is unchanged since 2011. It seems a silly reason to remove a module from the standard library

That's not the only reason:

  • It's a small module.
  • It's trivial to implement
  • It's outdated
  • It has a niche use case which is filled by web frameworks anyway

I will not insist - I will replicate the functionality in Rosencrantz when I find the time

Araq just said in #10604:

I don't like it at all, we should keep these modules in the stdlib if they are used and reasonably free of issues. They don't cost us much maintainance.

Closing this with the "won't fix" label.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

teroz picture teroz  Â·  3Comments

zzz125 picture zzz125  Â·  4Comments

capocasa picture capocasa  Â·  3Comments

liquid600pgm picture liquid600pgm  Â·  3Comments

juancarlospaco picture juancarlospaco  Â·  3Comments