Dispatch 0.10.0-beta1 with scala.concurrent.Future

[Nathan Hamblen]

Scala 2.9.3 includes a backport of 2.10's concurrency library, so instead of maintaining a split source tree as originally planned Dispatch will have a single source tree that is 2.9.3+ for version 0.10.x. The first beta of this is now published:

https://oss.sonatype.org/content/repositories/releases/net/databinder/dispatch/dispatch-core_2.9.3/

(It's in the branch `sippy` on github, if you're interested.)

The changes needed to adapt to scala.concurrent.Future are substantial, but in the long run in means we'll benefit from a common and growing toolset. dispatch.Promise is now a deprecated type alias for scala.concurrent.Future. The type dispatch.EnrichedFuture provides the either, option, and left and right projections that we like.

We lose support for implicit "guarantors" of map and flatMap operations, specifically IterableGuarantor. Generally you can do the same kinds of things with the `values` projection in combination with an explicit `flatMap`.

We also lose some retry magic in that Future can not "replay" itself the way that `dispatch.Promise` did. I don't see any way around that. Instead the retry functions take a function (promise: () => Future[T]), which is responsible for recreating the Future. With a nested function here and there you should be able to use this without significantly altering your code.

The type HttpExecutor has a few breaking changes if you were configuring it. It no longer configures timeouts or callback executors, as these are both expressed at the call site with scala.concurrent.Future.

Please try out the beta and write back to the list if you have any problems. I'd like to get this out fairly soon, it's been blocking us for a while. We can also continue to do 0.9.x releases if anyone needs them.

Nathna

[eugene yokota]

This sounds awesome!

-eugene

[eugene yokota]

I was able to port my repatch-github to 0.10.0-beta1 without much issue.

Much of the work had to do with lift-json => json4s migration: [1]

I also worked on the specs to make it more [futuristic][2]:

def repos1: MatchResult[Any] = {
    // `Client(Repos(user, repo)` constructs a request to
    // https://api.github.com/repos/dispatch/dispatch
    // Returned json object can then be parsed using `as_github.Repo`,
    // which returns a Repo case class
    val repos: Future[Repo] = Http(Client(Repos(user, repo)) > as_github.Repo)
    
    repos.completeOption must beSome.which { (x: Repo) =>
      x.full_name == "dispatch/dispatch"
    }.eventually
  }

Not sure if it's any better than blocking on them.

-eugene

  [1]: https://github.com/eed3si9n/repatch-github/commit/0c3758bbd0e9b6ce4eef765f70979d4412fd1f83

  [2]: https://github.com/eed3si9n/repatch-github/commit/ba621b61a71cc417c0c8aee1cee71f97bb8cab51

[Nathan Hamblen]

Yeah, I had to leave out the lift-json module since there is no 2.9.3 dependency for it yet.

Nice to see we are already benefiting from some futures interoperability, with 'eventually'. :-)

Nathan

--
You received this message because you are subscribed to the Google Groups "Dispatch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dispatch-scal...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.