Convert json_rpc.Server to take a Stream and StreamSink.

Convert json_rpc.Server to take a Stream and StreamSink.

R=rnystrom@google.com

Committed: https://code.google.com/p/dart/source/detail?r=37012

[Bob Nystrom, 2014-06-03 22:26:14]

This seems like a lot more complexity without that much value (at least, not
that's obvious to me).

It seems like a drag that anyone using this now has to deal with Streams and
StreamSinks where the method-based API would have worked for them fine. In
particular, this is now always async whether you want it to be or not.

Could this maybe be layered on top of the base server?

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/CHANGELOG.md
File pkg/json_rpc_2/CHANGELOG.md (right):

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/CHANGELOG.md#...
pkg/json_rpc_2/CHANGELOG.md:1: ## 1.0.0
0.1.0!

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
File pkg/json_rpc_2/lib/src/server.dart (right):

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:91: /// `WebSocket`), [responses] may be
omitted.
WebSocket is no longer a good example here since it doesn't work with the right
types.

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:107: /// Returns a [Future] that will
complete when the stream is closed of when it
"of" -> "or".

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:115: new Chain.current());
For programmatic errors like StateError, I think it's better to throw it
synchronously when possible.

[nweiz, 2014-06-03 23:37:00]

As we discussed in-person, the primary motivation behind this new API is to have
the same API between the server and the upcoming client class. I think that
consistency is worth a little difficulty here.

That said, I'm not convinced this API is actually hard to use on its own merits.
Most of the time, users will be attaching the server to a WebSocket object,
which is considerably simpler with this API (see the pub example).

> In particular, this is now always async whether you want it to be or not.

I'm not sure what you mean by this. The old API was thoroughly asynchronous,
with [Server.handleRequest] returning a Future. If anything, this API is less
so, since you don't have to deal with Futures explicitly unless you care about
the return value of [listen].

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/CHANGELOG.md
File pkg/json_rpc_2/CHANGELOG.md (right):

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/CHANGELOG.md#...
pkg/json_rpc_2/CHANGELOG.md:1: ## 1.0.0
On 2014/06/03 22:26:13, Bob Nystrom wrote:
> 0.1.0!

Done.

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
File pkg/json_rpc_2/lib/src/server.dart (right):

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:91: /// `WebSocket`), [responses] may be
omitted.
On 2014/06/03 22:26:13, Bob Nystrom wrote:
> WebSocket is no longer a good example here since it doesn't work with the
right
> types.

What do you mean? WebSocket sends and receives strings.

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:107: /// Returns a [Future] that will
complete when the stream is closed of when it
On 2014/06/03 22:26:13, Bob Nystrom wrote:
> "of" -> "or".

Done.

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:115: new Chain.current());
On 2014/06/03 22:26:13, Bob Nystrom wrote:
> For programmatic errors like StateError, I think it's better to throw it
> synchronously when possible.

Done.

[Bob Nystrom, 2014-06-04 16:40:43]

On 2014/06/03 23:37:00, nweiz wrote:
> As we discussed in-person, the primary motivation behind this new API is to
have
> the same API between the server and the upcoming client class. I think that
> consistency is worth a little difficulty here.

OK. In our discussion this was still pretty nebulous to me. I have a clearer
picture of what you had in mind now.

> > In particular, this is now always async whether you want it to be or not.
> 
> I'm not sure what you mean by this. The old API was thoroughly asynchronous,
> with [Server.handleRequest] returning a Future. 

Oh, right. Forgot about that.

[Bob Nystrom, 2014-06-04 16:40:48]

lgtm

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
File pkg/json_rpc_2/lib/src/server.dart (right):

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:91: /// `WebSocket`), [responses] may be
omitted.
On 2014/06/03 23:37:00, nweiz wrote:
> On 2014/06/03 22:26:13, Bob Nystrom wrote:
> > WebSocket is no longer a good example here since it doesn't work with the
> right
> > types.
> 
> What do you mean? WebSocket sends and receives strings.

Right, but this method sends and receives decoded maps and lists.

[nweiz, 2014-06-04 20:33:50]

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
File pkg/json_rpc_2/lib/src/server.dart (right):

https://codereview.chromium.org/309503005/diff/1/pkg/json_rpc_2/lib/src/serve...
pkg/json_rpc_2/lib/src/server.dart:91: /// `WebSocket`), [responses] may be
omitted.
On 2014/06/04 16:40:48, Bob Nystrom wrote:
> On 2014/06/03 23:37:00, nweiz wrote:
> > On 2014/06/03 22:26:13, Bob Nystrom wrote:
> > > WebSocket is no longer a good example here since it doesn't work with the
> > right
> > > types.
> > 
> > What do you mean? WebSocket sends and receives strings.
> 
> Right, but this method sends and receives decoded maps and lists.

Oh, gotcha. Changed.

[nweiz, 2014-06-04 20:40:52]

Committed patchset #3 manually as r37012 (presubmit successful).