I've been manually confirming that the tests are green before committing, but I should really set up CI sooner or later to make sure I never miss a commit.

The current syntax of the routes! macro requires the author to specify every method each resource supports, e.g.:

routes! {
     resource Photo => ["get", "index", "put"] { ... }
}

The user then additionally provides an impl of the trait associated with each method for Photo.

This is redundant work, but its necessary for the macro to be expanded in a way which attaches each method for that resource (see the methods! macro in the current version of the source).

With lattice specialization, we could instead provide a single entry point, specialized for all of the combinations of methods that could be supported. This would be a lot of boilerplate for cargonauts, but it would save much more boilerplate for cargonauts users. For example:

struct<R: router::Router> Router<R> {
    // underlying method specific functions
    fn attach_get<T: Get>(&mut self) { ... }
    fn attach_index<T: Index>(&mut self) { ... }

    // specialized entry point method
    default fn attach_methods<T>(&mut self) {
        // base case is null - you have defined no methods for this resource
    }
    default fn attach_methods<T: Get>(&mut self) {
        self.attach_get::<T>();
    }
    default fn attach_methods<T: Index>(&mut self) {
        self.attach_index::<T>();
    }
    fn attach_methods<T: Get + Index>(&mut self) {
        self.attach_get::<T>();
        self.attach_index::<T>();
    }
}

This requires lattice specialization because the method traits do not form a specialization order between them.

There's an issue with max() being implemented in both the standard library and in (a presumably older version of) petgraph that's causing an error when building the 0.2 version of cargonauts now. This is only an issue because this is the branch installed by default with the CLI tool so the getting started experience was a little rocky.

Changing the autogenerated Cargo.toml file from branch = "0.2-release" to branch = "master" fixes it (so this should hopefully close whenever the next release is pinned in the CLI).

This PR is a one line change that prints out Running on 127.0.0.1:7878 or whatever address it is running on.

When trying out cargonauts I was confused about which port it was running on, so I thought it might be useful to print it out.

Opening a PR because this changes the Cargo.toml to pull serde from a fork & I'm not sure about deciding to commit to that (waiting to see how things shake out in the serde PR).

This PR changes several things:

1. Includes are now represented using a trait object, because the fork of serde used now supports that.
2. Supports sparse fieldsets by defining a new "Represent" trait, which is a variant on "Serialize" that takes a field set as an additional argument. A derive macro for the Represent trait is forthcoming.
3. Defines a new "Presenter" layer. This is a big change and larger orthogonal to the others (but for a while I wasn't sure it would be), and maybe it can be split out into its own commit. JsonApi is now just a "presenter" layer, which defines how responses are presented. Other people can define alternative "presenters" out of tree, and in the future I want to support at least a server-side rendered templated HTML "presenter" in tree, probably built on a variant of handlebars or moustache or whatever.

cargonauts-rs/cargonauts now has a Chat Room on Gitter

@withoutboats has just created a chat room. You can visit it here: https://gitter.im/cargonauts-rs/cargonauts.

This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.

Happy chatting.

PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

compass-rose is a replacement for the routes! macro, a compiler for the routes DSL based on LALRPOP. It will be more robust and permissive, have better error messages, and support multiple backends aside from generating routing code - such as swagger documentation.

On this page, https://cargonauts-rs.github.io/cargonauts/ping.html, the docs talk about using chrono and version 0.3.1. That version appears to have been yanked https://crates.io/crates/chrono/0.3.1. The current latest version if 0.4 which switches to using Utc vs UTC. (note the uppercase). Trying to build the example with chrono 0.4 results in ^^^ noUTCin the root.

I noticed on #7 that you mention being able to dynamically load templates and assets, and that got me wondering about how you imagine cargonauts users will handle assets.

I recently released a crate for embedding entire directory trees in your binary, so kinda like include_str, but on steroids. Would something like that be useful for when people want to deploy their apps to production?

On the dynamic reloading side of things, it sounds like you want something which can watch a directory, caching resources which you've served in the past, and reloading them when they are changed (presumably with notify). Have you started work on any of the asset pipeline stuff yet? I'd be keen to help out.

I'm interested in helping with this project, but as a Rust noob, my code contributions might be minimal. I do have a modicum of skill with design, so I would like to contribute with a logo and some general design for the project.

I've attached an idea for a logo, which is heavily influenced by the badges worn by astro/cosmo-nauts. I am not proposing this exact thing, I really just wanted to attach something to stimulate discussion.

cargonauts has some integration tests that run the examples in the examples directory and make requests of them, to make sure the whole system is working at least kind of correctly.

These have proven to be pretty flakey on CI, failing requests with ConnectionRefused a litle too often. I don't know why this is but would be great for this to get fixed somehow. Ideas:

1. Figure out why this happens on CI (doesnt happen on my machine) and maybe there's a config on travis that could be changed to fix it.
2. Maybe there's a small change to the tests that could fix the problem.
3. If not, figure out another way to get the same end-to-end testing without actually performing a TCP connection.

This adds two methods:

• on_pool, which allows you to run a closure on the CPU pool.
• sync_conn, which allows you to access a synchronous connection, managed by r2d2 (it is not possible to set up such a connection yet; more coming!).

The CPU pool has 4 * the number of CPU threads. Someday this number will be configurable.