Add testable interface for datastore.

Add testable interface for datastore.

Includes the ability to manipulate the 'eventual consistency' state of the
datastore, as well as the ability to add compound indicies.

R=dnj@google.com, dnj@chromium.org, estaab@chromium.org, tandrii@chromium.org, vadimsh@chromium.org
BUG=

Committed: https://github.com/luci/gae/commit/f9c08d41e48e4eceea0b45bf963d3e8eeaf05eb4

[iannucci, 2015-08-14 19:54:48]

On 2015/08/10 21:42:49, iannucci wrote:

PTAL, this is rebased and ready to rock

[iannucci, 2015-08-14 22:06:38]

On 2015/08/14 19:54:48, iannucci wrote:
> On 2015/08/10 21:42:49, iannucci wrote:
> 
> PTAL, this is rebased and ready to rock

(This is also the first one in the chain :D)

[dnj (Google), 2015-08-14 22:53:54]

dnj@google.com changed reviewers:
+ dnj@google.com

[dnj (Google), 2015-08-14 22:53:55]

Looks mostly good. Few comments/questions.

https://codereview.chromium.org/1285703002/diff/20001/impl/dummy/dummy.go
File impl/dummy/dummy.go (right):

https://codereview.chromium.org/1285703002/diff/20001/impl/dummy/dummy.go#new...
impl/dummy/dummy.go:83: func (ds) Testable() datastore.Testable { panic(ni()) }
Interface docs suggests this should return "nil" rather than panic.

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/inter...
File service/datastore/interface.go (right):

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/inter...
service/datastore/interface.go:146: Testable() Testable
Since most implementations return nil here, should this really be a
datastore.Interface method? It feels like it's bloating the interface.

I think that "Testable" and all supporting functions should be moved into
impl/memory, since:
(a) it's the only thing that's going to implement Testable, and
(b) different implementations down the road may have different controls or
testable primitives.

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/seria...
File service/datastore/serialize.go (right):

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/seria...
service/datastore/serialize.go:18: const MaxIndexColumns = 64
Can you document why 64?

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/seria...
service/datastore/serialize.go:388: c.Direction = dir != 0
Since you use constants (ASCENDING) for writing, you should use them here for
reading:
switch dir {
case 0:
  c.Direction = ASCENDING
default:
  c.Direction = DESCENDING
}

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/testa...
File service/datastore/testable.go (right):

https://codereview.chromium.org/1285703002/diff/20001/service/datastore/testa...
service/datastore/testable.go:13: AddIndexes(...*IndexDefinition)
Should mention that this an panic if a non-compound index is added. Or maybe it
should return error?

[iannucci, 2015-08-15 01:59:25]

done

https://chromiumcodereview.appspot.com/1285703002/diff/20001/impl/dummy/dummy.go
File impl/dummy/dummy.go (right):

https://chromiumcodereview.appspot.com/1285703002/diff/20001/impl/dummy/dummy...
impl/dummy/dummy.go:83: func (ds) Testable() datastore.Testable { panic(ni()) }
On 2015/08/14 22:53:54, dnj (Google) wrote:
> Interface docs suggests this should return "nil" rather than panic.

Done.

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
File service/datastore/interface.go (right):

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
service/datastore/interface.go:146: Testable() Testable
On 2015/08/14 22:53:54, dnj (Google) wrote:
> Since most implementations return nil here, should this really be a
> datastore.Interface method? It feels like it's bloating the interface.
> 
> I think that "Testable" and all supporting functions should be moved into
> impl/memory, since:
> (a) it's the only thing that's going to implement Testable, and
> (b) different implementations down the road may have different controls or
> testable primitives.
> 

There's no way to cast to it, which is why I'm doing this in the first place.
memory doesn't have the necessary access to the types to get a Testable from a
RawInterface.

I've moved this down to RawInterface only

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
File service/datastore/serialize.go (right):

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
service/datastore/serialize.go:18: const MaxIndexColumns = 64
On 2015/08/14 22:53:54, dnj (Google) wrote:
> Can you document why 64?

done

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
service/datastore/serialize.go:388: c.Direction = dir != 0
On 2015/08/14 22:53:54, dnj (Google) wrote:
> Since you use constants (ASCENDING) for writing, you should use them here for
> reading:
> switch dir {
> case 0:
>   c.Direction = ASCENDING
> default:
>   c.Direction = DESCENDING
> }

Done.

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
File service/datastore/testable.go (right):

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
service/datastore/testable.go:13: AddIndexes(...*IndexDefinition)
On 2015/08/14 22:53:54, dnj (Google) wrote:
> Should mention that this an panic if a non-compound index is added. Or maybe
it
> should return error?

it's for testing, so I'd rather have it panic if the test author does something
stupid.

documented the panic.

[dnj (Google), 2015-08-15 02:07:53]

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
File service/datastore/interface.go (right):

https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
service/datastore/interface.go:146: Testable() Testable
On 2015/08/15 01:59:25, iannucci wrote:
> On 2015/08/14 22:53:54, dnj (Google) wrote:
> > Since most implementations return nil here, should this really be a
> > datastore.Interface method? It feels like it's bloating the interface.
> > 
> > I think that "Testable" and all supporting functions should be moved into
> > impl/memory, since:
> > (a) it's the only thing that's going to implement Testable, and
> > (b) different implementations down the road may have different controls or
> > testable primitives.
> > 
> 
> There's no way to cast to it, which is why I'm doing this in the first place.
> memory doesn't have the necessary access to the types to get a Testable from a
> RawInterface.
> 
> I've moved this down to RawInterface only

I was thinking something like:

testable := memory.Testable(ctx)

func Testable(ctx context.Context) {
  d := ds.getUnfiltered(ctx)
  //          ^ make me public
  if d != nil {
    if t, ok := d.(*dsImpl); ok {
      return t
    }
  }
}

[iannucci, 2015-08-15 02:18:27]

On 2015/08/15 02:07:53, dnj (Google) wrote:
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> File service/datastore/interface.go (right):
> 
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> service/datastore/interface.go:146: Testable() Testable
> On 2015/08/15 01:59:25, iannucci wrote:
> > On 2015/08/14 22:53:54, dnj (Google) wrote:
> > > Since most implementations return nil here, should this really be a
> > > datastore.Interface method? It feels like it's bloating the interface.
> > > 
> > > I think that "Testable" and all supporting functions should be moved into
> > > impl/memory, since:
> > > (a) it's the only thing that's going to implement Testable, and
> > > (b) different implementations down the road may have different controls or
> > > testable primitives.
> > > 
> > 
> > There's no way to cast to it, which is why I'm doing this in the first
place.
> > memory doesn't have the necessary access to the types to get a Testable from
a
> > RawInterface.
> > 
> > I've moved this down to RawInterface only
> 
> I was thinking something like:
> 
> testable := memory.Testable(ctx)
> 
> func Testable(ctx context.Context) {
>   d := ds.getUnfiltered(ctx)
>   //          ^ make me public
>   if d != nil {
>     if t, ok := d.(*dsImpl); ok {
>       return t
>     }
>   }
> }

Hm... so I would store the same datastore in the context twice? How would
transactions work? I don't think I like that... unless you meant something else?

[iannucci, 2015-08-15 02:19:10]

On 2015/08/15 02:18:27, iannucci wrote:
> On 2015/08/15 02:07:53, dnj (Google) wrote:
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > File service/datastore/interface.go (right):
> > 
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > service/datastore/interface.go:146: Testable() Testable
> > On 2015/08/15 01:59:25, iannucci wrote:
> > > On 2015/08/14 22:53:54, dnj (Google) wrote:
> > > > Since most implementations return nil here, should this really be a
> > > > datastore.Interface method? It feels like it's bloating the interface.
> > > > 
> > > > I think that "Testable" and all supporting functions should be moved
into
> > > > impl/memory, since:
> > > > (a) it's the only thing that's going to implement Testable, and
> > > > (b) different implementations down the road may have different controls
or
> > > > testable primitives.
> > > > 
> > > 
> > > There's no way to cast to it, which is why I'm doing this in the first
> place.
> > > memory doesn't have the necessary access to the types to get a Testable
from
> a
> > > RawInterface.
> > > 
> > > I've moved this down to RawInterface only
> > 
> > I was thinking something like:
> > 
> > testable := memory.Testable(ctx)
> > 
> > func Testable(ctx context.Context) {
> >   d := ds.getUnfiltered(ctx)
> >   //          ^ make me public
> >   if d != nil {
> >     if t, ok := d.(*dsImpl); ok {
> >       return t
> >     }
> >   }
> > }
> 
> Hm... so I would store the same datastore in the context twice? How would
> transactions work? I don't think I like that... unless you meant something
else?

Also, I do plan on implementing aetest at some point, which would be a second
implementor. The Testable interface should be the same across all testable
implementations I think...

[dnj (Google), 2015-08-15 02:29:48]

On 2015/08/15 02:18:27, iannucci wrote:
> On 2015/08/15 02:07:53, dnj (Google) wrote:
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > File service/datastore/interface.go (right):
> > 
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > service/datastore/interface.go:146: Testable() Testable
> > On 2015/08/15 01:59:25, iannucci wrote:
> > > On 2015/08/14 22:53:54, dnj (Google) wrote:
> > > > Since most implementations return nil here, should this really be a
> > > > datastore.Interface method? It feels like it's bloating the interface.
> > > > 
> > > > I think that "Testable" and all supporting functions should be moved
into
> > > > impl/memory, since:
> > > > (a) it's the only thing that's going to implement Testable, and
> > > > (b) different implementations down the road may have different controls
or
> > > > testable primitives.
> > > > 
> > > 
> > > There's no way to cast to it, which is why I'm doing this in the first
> place.
> > > memory doesn't have the necessary access to the types to get a Testable
from
> a
> > > RawInterface.
> > > 
> > > I've moved this down to RawInterface only
> > 
> > I was thinking something like:
> > 
> > testable := memory.Testable(ctx)
> > 
> > func Testable(ctx context.Context) {
> >   d := ds.getUnfiltered(ctx)
> >   //          ^ make me public
> >   if d != nil {
> >     if t, ok := d.(*dsImpl); ok {
> >       return t
> >     }
> >   }
> > }
> 
> Hm... so I would store the same datastore in the context twice? How would
> transactions work? I don't think I like that... unless you meant something
else?

Oh good point, forgot about the transaction impact. Could do:

func Testable(d datastore.Interface) Testable {
  if t, ok := d.(*dsImpl); ok {
    return t
  }
  return nil
}

> Also, I do plan on implementing aetest at some point, which would be a second
> implementor. The Testable interface should be the same across all testable
> implementations I think...

Maybe - it seems like Testable (like RawDatastore in this case) would end up
being the superset of all of its implementations' methods. I think it's accurate
to say, "here is a memory datastore. It's testable, and here are the knobs you
can turn." Do you foresee a situation where consistency in the testing interface
is used? I figure a test suite would pick either memory, aetest, or w/e else
based on its testing needs.

[iannucci, 2015-08-15 16:12:58]

On 2015/08/15 02:29:48, dnj (Google) wrote:
> On 2015/08/15 02:18:27, iannucci wrote:
> > On 2015/08/15 02:07:53, dnj (Google) wrote:
> > >
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > > File service/datastore/interface.go (right):
> > > 
> > >
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > > service/datastore/interface.go:146: Testable() Testable
> > > On 2015/08/15 01:59:25, iannucci wrote:
> > > > On 2015/08/14 22:53:54, dnj (Google) wrote:
> > > > > Since most implementations return nil here, should this really be a
> > > > > datastore.Interface method? It feels like it's bloating the interface.
> > > > > 
> > > > > I think that "Testable" and all supporting functions should be moved
> into
> > > > > impl/memory, since:
> > > > > (a) it's the only thing that's going to implement Testable, and
> > > > > (b) different implementations down the road may have different
controls
> or
> > > > > testable primitives.
> > > > > 
> > > > 
> > > > There's no way to cast to it, which is why I'm doing this in the first
> > place.
> > > > memory doesn't have the necessary access to the types to get a Testable
> from
> > a
> > > > RawInterface.
> > > > 
> > > > I've moved this down to RawInterface only
> > > 
> > > I was thinking something like:
> > > 
> > > testable := memory.Testable(ctx)
> > > 
> > > func Testable(ctx context.Context) {
> > >   d := ds.getUnfiltered(ctx)
> > >   //          ^ make me public
> > >   if d != nil {
> > >     if t, ok := d.(*dsImpl); ok {
> > >       return t
> > >     }
> > >   }
> > > }
> > 
> > Hm... so I would store the same datastore in the context twice? How would
> > transactions work? I don't think I like that... unless you meant something
> else?
> 
> Oh good point, forgot about the transaction impact. Could do:
> 
> func Testable(d datastore.Interface) Testable {
>   if t, ok := d.(*dsImpl); ok {
>     return t
>   }
>   return nil
> }
> 
> > Also, I do plan on implementing aetest at some point, which would be a
second
> > implementor. The Testable interface should be the same across all testable
> > implementations I think...
> 
> Maybe - it seems like Testable (like RawDatastore in this case) would end up
> being the superset of all of its implementations' methods. I think it's
accurate
> to say, "here is a memory datastore. It's testable, and here are the knobs you
> can turn." Do you foresee a situation where consistency in the testing
interface
> is used? I figure a test suite would pick either memory, aetest, or w/e else
> based on its testing needs.

Yes, I need to simulate inconsistent datastore scenarios to ensure that tumble
handles them well.

[iannucci, 2015-08-15 16:16:42]

On 2015/08/15 16:12:58, iannucci wrote:
> On 2015/08/15 02:29:48, dnj (Google) wrote:
> > On 2015/08/15 02:18:27, iannucci wrote:
> > > On 2015/08/15 02:07:53, dnj (Google) wrote:
> > > >
> > >
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > > > File service/datastore/interface.go (right):
> > > > 
> > > >
> > >
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > > > service/datastore/interface.go:146: Testable() Testable
> > > > On 2015/08/15 01:59:25, iannucci wrote:
> > > > > On 2015/08/14 22:53:54, dnj (Google) wrote:
> > > > > > Since most implementations return nil here, should this really be a
> > > > > > datastore.Interface method? It feels like it's bloating the
interface.
> > > > > > 
> > > > > > I think that "Testable" and all supporting functions should be moved
> > into
> > > > > > impl/memory, since:
> > > > > > (a) it's the only thing that's going to implement Testable, and
> > > > > > (b) different implementations down the road may have different
> controls
> > or
> > > > > > testable primitives.
> > > > > > 
> > > > > 
> > > > > There's no way to cast to it, which is why I'm doing this in the first
> > > place.
> > > > > memory doesn't have the necessary access to the types to get a
Testable
> > from
> > > a
> > > > > RawInterface.
> > > > > 
> > > > > I've moved this down to RawInterface only
> > > > 
> > > > I was thinking something like:
> > > > 
> > > > testable := memory.Testable(ctx)
> > > > 
> > > > func Testable(ctx context.Context) {
> > > >   d := ds.getUnfiltered(ctx)
> > > >   //          ^ make me public
> > > >   if d != nil {
> > > >     if t, ok := d.(*dsImpl); ok {
> > > >       return t
> > > >     }
> > > >   }
> > > > }
> > > 
> > > Hm... so I would store the same datastore in the context twice? How would
> > > transactions work? I don't think I like that... unless you meant something
> > else?
> > 
> > Oh good point, forgot about the transaction impact. Could do:
> > 
> > func Testable(d datastore.Interface) Testable {
> >   if t, ok := d.(*dsImpl); ok {
> >     return t
> >   }
> >   return nil
> > }
> > 
> > > Also, I do plan on implementing aetest at some point, which would be a
> second
> > > implementor. The Testable interface should be the same across all testable
> > > implementations I think...
> > 
> > Maybe - it seems like Testable (like RawDatastore in this case) would end up
> > being the superset of all of its implementations' methods. I think it's
> accurate
> > to say, "here is a memory datastore. It's testable, and here are the knobs
you
> > can turn." Do you foresee a situation where consistency in the testing
> interface
> > is used? I figure a test suite would pick either memory, aetest, or w/e else
> > based on its testing needs.
> 
> Yes, I need to simulate inconsistent datastore scenarios to ensure that tumble
> handles them well.

Oh, I see what you're saying, nevermind.

The other issue is that I didn't want to include all the testing interfaces in
the same
package. What you're suggesting is that I have memory.TaskqueueTestable,
memory.GetTaskqueueTestable, memory.DatastoreTestable, 
memory.GetDatastoreTestable, and all the support methods (including copy+paste
from the logic that's already in service/taskqueue and service/datastore).

It seems more complex to me, and I'm still not sure what the benefit is?

[iannucci, 2015-08-15 16:19:12]

On 2015/08/15 16:16:42, iannucci wrote:
> On 2015/08/15 16:12:58, iannucci wrote:
> > On 2015/08/15 02:29:48, dnj (Google) wrote:
> > > On 2015/08/15 02:18:27, iannucci wrote:
> > > > On 2015/08/15 02:07:53, dnj (Google) wrote:
> > > > >
> > > >
> > >
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > > > > File service/datastore/interface.go (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://chromiumcodereview.appspot.com/1285703002/diff/20001/service/datastor...
> > > > > service/datastore/interface.go:146: Testable() Testable
> > > > > On 2015/08/15 01:59:25, iannucci wrote:
> > > > > > On 2015/08/14 22:53:54, dnj (Google) wrote:
> > > > > > > Since most implementations return nil here, should this really be
a
> > > > > > > datastore.Interface method? It feels like it's bloating the
> interface.
> > > > > > > 
> > > > > > > I think that "Testable" and all supporting functions should be
moved
> > > into
> > > > > > > impl/memory, since:
> > > > > > > (a) it's the only thing that's going to implement Testable, and
> > > > > > > (b) different implementations down the road may have different
> > controls
> > > or
> > > > > > > testable primitives.
> > > > > > > 
> > > > > > 
> > > > > > There's no way to cast to it, which is why I'm doing this in the
first
> > > > place.
> > > > > > memory doesn't have the necessary access to the types to get a
> Testable
> > > from
> > > > a
> > > > > > RawInterface.
> > > > > > 
> > > > > > I've moved this down to RawInterface only
> > > > > 
> > > > > I was thinking something like:
> > > > > 
> > > > > testable := memory.Testable(ctx)
> > > > > 
> > > > > func Testable(ctx context.Context) {
> > > > >   d := ds.getUnfiltered(ctx)
> > > > >   //          ^ make me public
> > > > >   if d != nil {
> > > > >     if t, ok := d.(*dsImpl); ok {
> > > > >       return t
> > > > >     }
> > > > >   }
> > > > > }
> > > > 
> > > > Hm... so I would store the same datastore in the context twice? How
would
> > > > transactions work? I don't think I like that... unless you meant
something
> > > else?
> > > 
> > > Oh good point, forgot about the transaction impact. Could do:
> > > 
> > > func Testable(d datastore.Interface) Testable {
> > >   if t, ok := d.(*dsImpl); ok {
> > >     return t
> > >   }
> > >   return nil
> > > }

I said this before, but I'll say it again; this does not work, which is why I
already introduced
the luci/gae-wide Testable concept. Some services (like datastore), apply
permanent filters
over the raw implementation (e.g. checkFilter), to guarantee that
implementations need to
do less redundant error checking work. The memory package doesn't have the
ability to
peel this type away, only the service package itself does.

> > > 
> > > > Also, I do plan on implementing aetest at some point, which would be a
> > second
> > > > implementor. The Testable interface should be the same across all
testable
> > > > implementations I think...
> > > 
> > > Maybe - it seems like Testable (like RawDatastore in this case) would end
up
> > > being the superset of all of its implementations' methods. I think it's
> > accurate
> > > to say, "here is a memory datastore. It's testable, and here are the knobs
> you
> > > can turn." Do you foresee a situation where consistency in the testing
> > interface
> > > is used? I figure a test suite would pick either memory, aetest, or w/e
else
> > > based on its testing needs.
> > 
> > Yes, I need to simulate inconsistent datastore scenarios to ensure that
tumble
> > handles them well.
> 
> Oh, I see what you're saying, nevermind.
> 
> The other issue is that I didn't want to include all the testing interfaces in
> the same
> package. What you're suggesting is that I have memory.TaskqueueTestable,
> memory.GetTaskqueueTestable, memory.DatastoreTestable, 
> memory.GetDatastoreTestable, and all the support methods (including copy+paste
> from the logic that's already in service/taskqueue and service/datastore).
> 
> It seems more complex to me, and I'm still not sure what the benefit is?

[dnj (Google), 2015-08-15 19:01:15]

> > The other issue is that I didn't want to include all the testing interfaces
in
> > the same
> > package. What you're suggesting is that I have memory.TaskqueueTestable,
> > memory.GetTaskqueueTestable, memory.DatastoreTestable, 
> > memory.GetDatastoreTestable, and all the support methods (including
copy+paste
> > from the logic that's already in service/taskqueue and service/datastore).
> > 
> > It seems more complex to me, and I'm still not sure what the benefit is?

Yeah, that does seem unnecessarily complex.

My _only_ concern is interface creep: with the way things are set up, each
interface must declare the aggregate superset of each of its implementation's
offerings. This makes sense when they all offer the same thing, a front-end to
appengine datastore API, but it looks like we don't have a strong answer to
supporting implementation-specific capabilities (in this case, memory/testable).

I'm okay punting this down the road and hoping that:
(a) there is no future need to introduce new implementation-specific
capabilities
(b) the testing interface is sufficiently universal for all implementations'
testability parameters.

These don't seem unreasonable given the current plans; however, I think it is
something to think about.

[iannucci, 2015-08-15 19:41:33]

Yeah OK that makes sense. We can burn that bridge when we get to it :P

On Sat, Aug 15, 2015, 12:01  <dnj@google.com> wrote:

> > > The other issue is that I didn't want to include all the testing
> > interfaces
> in
> > > the same
> > > package. What you're suggesting is that I have
> memory.TaskqueueTestable,
> > > memory.GetTaskqueueTestable, memory.DatastoreTestable,
> > > memory.GetDatastoreTestable, and all the support methods (including
> copy+paste
> > > from the logic that's already in service/taskqueue and
> > service/datastore).
> > >
> > > It seems more complex to me, and I'm still not sure what the benefit
> is?
>
> Yeah, that does seem unnecessarily complex.
>
> My _only_ concern is interface creep: with the way things are set up, each
> interface must declare the aggregate superset of each of its
> implementation's
> offerings. This makes sense when they all offer the same thing, a front-end
> to
> appengine datastore API, but it looks like we don't have a strong answer to
> supporting implementation-specific capabilities (in this case,
> memory/testable).
>
> I'm okay punting this down the road and hoping that:
> (a) there is no future need to introduce new implementation-specific
> capabilities
> (b) the testing interface is sufficiently universal for all
> implementations'
> testability parameters.
>
> These don't seem unreasonable given the current plans; however, I think it
> is
> something to think about.
>
> https://codereview.chromium.org/1285703002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[dnj (Google), 2015-08-15 19:44:58]

Sounds good, lgtm!

[iannucci, 2015-08-15 21:52:39]

Committed patchset #4 (id:60001) manually as
f9c08d41e48e4eceea0b45bf963d3e8eeaf05eb4 (presubmit successful).