Implement Rocket::launch that returns Result about rocket HOT 8 CLOSED

A callback on success would allow further actions, like launching an embedded browser to connect to the resulting listening port (if a port was picked by the system instead the Config).

from rocket.

Would a Rocket::launch() -> Result still block on success?

I ask because, if so, I'd suggest for a slightly lower-level interface to be exposed as well. That'd allow framework users to start tasks after successful binds, for instance.

We could keep launch but also expose optional separate bind and run loop methods, say, countdown and takeoff. Well, substituting those tongue-in-cheek names but you get the idea. 😄

Thoughts? Also, how could a Rust newbie help?

from rocket.

Yes, launch should block. It is consistent with how other web servers work (iron, nickel) and besides, how would we make it not block? Make Rocket run launch in a thread? That seems like it would create its own set of issues.

I like the idea of separating bind and run loop, if it would be possible to bind to multiple ports and addresses (possibly with different http/s combinations) and then handle connections from all with a single run loop, that would be amazing. However, I am not sure if it is even possible. AFAIK iron cannot do that, not sure if hyper can.

from rocket.

I ask because, if so, I'd suggest for a slightly lower-level interface to be exposed as well. That'd allow framework users to start tasks after successful binds, for instance.

This case is solved by #210 (still a work in progress)

from rocket.

I think we can be a tad-bit more clever here, but I agree. Let's get this in for 0.3.

from rocket.

An interesting hack would be to make ::launch() use a new thread to start the server and then .join() it in the Drop (which I think is default for rust's threads).

Your normal examples would all work the same but something like this would also work:

fn main() {
  // ignore the obvious port conflict here
  let _ = rocket::ignite().launch();
  let _ = rocket::ignite().launch();
}

Yes, launch should block. It is consistent with how other web servers work (iron, nickel) and besides, how would we make it not block?

Iron does not block. At least it doesn't in the current version. I'm guessing it uses a similar approach to what I say above.

from rocket.

Someone (maybe you?) proposed this, but it just feels like too much magic. I had in mind something much simpler: return a RocketError where RocketError implements Drop and simply prints the error out to the console. This exactly emulates the behavior we have right now, and the behavior most will want, while still letting someone catch it.

from rocket.

I can't imagine myself ever wanting multiple rocket servers running from the same main so don't want it that much. It's super easy to have N binaries in the same cargo project anyway.

I'm fine with the simpler option.

from rocket.