Ryman
commented
8 years ago 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
nickelrepo 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/securewhich transitively depends onopenssl, 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
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...