Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is nickel_cookies not a part of Nickel? #1

Open
matt2xu opened this issue Mar 2, 2016 · 2 comments
Open

Why is nickel_cookies not a part of Nickel? #1

matt2xu opened this issue Mar 2, 2016 · 2 comments

Comments

@matt2xu
Copy link

matt2xu commented Mar 2, 2016

Given the focus of Nickel which is to provide an Expressjs-inspired web framework(*), I would expect that cookies are handled out-of-the-box. Instead, I just found out that I need to use this crate; and I had to use the git version as I did not find it on crates.io.

Why are cookies treated as a separate crate, when it is central to many Web applications?

(*) which I find much superior to Iron's "everything is a plugin", because in Iron's case this creates an unfortunate feeling of "where are my batteries" for everything you want to do, even the most mundane tasks like serving static files and routing requests...

@Ryman
Copy link
Member

Ryman commented Mar 3, 2016

There are a few reasons that I can recall:

  • The Cookies (and Session) api was being iterated a lot, and if we wanted to be able to try it without having to increment the nickel version everytime we did something breaking then having it in a separate crate with its own versioning scheme is better. This would be less of an issue if libs could tag things as #[unstable(..)].
  • Having extra things in the main nickel repo only seems to give people the impression that they can't build their own extensions out of tree, having something out of tree can be an example of how to build things without having to relying on internal features.
  • Build times become an issue with the current rust compiler when things start to grow bigger, having things in separate crates gave better turnarounds for working on nickel_cookies. Hopefully this is less of an issue when incremental compilation lands.
  • I had a preference to have secure cookies by default, but this brings an additional default dependency on cookie/secure which transitively depends on openssl, which some people don't have an easy time building (windows mostly).

We did initially plan to rework things so nickel could still re-export cookies or other major crates through feature flags, letting us develop in downstream crates but package them as a 'batteries included' package, but we haven't really had any push towards that as nobody has really been pushing for that integration (perhaps it's worth looking at again though!). cc @cburgdorf @simonpersson

and I had to use the git version as I did not find it on crates.io.

Pushing to crates.io is an omission that I will fix, I think the api should be fine to push an initial version up.

@jolhoeft
Copy link
Member

Unless I get objections, I will be pulling nickel-cookies into nickel as a sub-crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants