Is a compute API something that would potentially be interesting ?
I'm not a fan of using the auto-generated APIs so a nicely handmade compute API is something I'd be interested in contributing.

Some key things to do...

• Show how to "go get" the package
• Show how to import the package
• Show how to authenticate
• Show how to create a connection to GCS

Add support for the highly-performant Protobuf protocol.

We export a method to flag a query to run in eventual consistency but, our lookup request proto is not setting the right reading option.

https://github.com/GoogleCloudPlatform/gcloud-golang/blob/master/datastore/query.go#L133
https://cloud.google.com/datastore/docs/apis/v1beta2/datasets/lookup

The v3 appengine client sets the allow_multiple_eg flag to true when a transaction is set as XG. I can't find a similar field in the v1 public proto, how does this work in v1 ?

Buckets are the basic containers that hold your data

Details at /storage/docs/concepts-techniques.

How should a proto for an ancestor query look ? It seems to me that ancestor queries are now done with a Filter, but I don't understand what the "property" field should be set to when using the HAS_ANCESTOR operator.

Document the design and execution plan for unit testing.

Anyone should be able to read this message once this is public.

The v3 API has a concept of "indexValues" which are opaque values because they don't have a valid "meaning" in the go world, they were used when things were loaded directly from an index due to a projection being set that way.
Am I correct in assuming this has been nuked and those now behave just like anything else and have a correct Value proto filled up for them ?

What is the current state of the datastore package in the experimental branch ?

I'm looking to write a program using datastore on compute engine and need such a package, and I'd like to help out however possible.
Is the current state of the experimental package what I should base myself on ? It hasn't been updated in a while now.

I'm currently going through the testsuite converted from appengine.
One of the tests still failing is the ones involving saving/loading slices.

How should slices be loaded/saved ?
The two options seem to be either by having the same property mentioned multiple times, like this:

key:<path_element:<kind:"kind" name:"name0" > > property:<name:"B" value:<boolean_value:true > > property:<name:"F" value:<double_value:7 > > property: <name:"F" value:<double_value:8 > > property <name:"F" value:<double_value:9 > >

The other would be to use the list_value repeated field and only have the F property mentioned once, but containing 3 of the list_value repeated field.

the old v3 seems the use the former approach, but the later makes more sense for the v1 to me, is this correct ?

Objects are the individual pieces of data that you store in Google Cloud Storage

We shouldn't return an error if there are deferred entities on the results, we should return a known error for the corresponding keys.

See https://github.com/GoogleCloudPlatform/gcloud-golang/blob/master/datastore/datastore.go#L343

When working with datasets, the Datastore backend will normalize any empty datasets to the dataset of the calling application. This should be preferred to prepending "s~" to dataset ids as that is not always a valid operation.

Related discussion is on #57.

I'd like confirmation on the behaviour of pagination with regards to the two MoreResultTypes listed in the title.
If I understand it correctly, pagination is only available when the result type is NOT_FINISHED, is this correct ?

Those 3 boolean flags are not available anymore with no obvious replacement, what to do with them ? Are they passed some other way ? Specificly keys_only is something I still want to support but can't find an obvious way to do it.

Right now Datastore doesn't natively support OR filters, however it is a feature we'd like to support. When switching from GAE Datastore to Cloud Datastore filters were explicitly changed from being represented as a list to a more hierarchical model to support this. There should be a plan in place for how to expose this, since now filters are assumed to be AND'ed together.

Data objects in the Datastore are known as entities. Each entity in the Datastore has a key that uniquely identifies it.

Details at /datastore/docs/concepts/entities.

The v1 proto does not have a "Next" call accepting a NextQuery proto. I assume this means next queries are instead mapped to a query with a StartCursor set to the end cursor received in the previous RunQueryResult ?

Details at /storage/docs/accesscontrol.

Document the design and execution plan for functional testing.

Do you have a plan for providing a library for testing which allows you to easily write unit tests of your application?

In the v3 proto file used by appengine, a lot of use is made of the "meaning" field to keep track whether something is a geopoint, byte array, time, etc.
In the v1 public API, the meaning field is specificly marked as "do not use", and additional Value fields have been added, it mostly maps over nicely, however, GeoPoint seems to be gone and I'm somewhat at loss as to how geopoint should be implemented with the new v1 proto API.

Datastore uses many generic keys such as base_url, transaction, etc. https://github.com/GoogleCloudPlatform/gcloud-golang/blob/master/datastore/datastore.go#L96

Either prefix these keys, or datastore should define its own key type.

https://github.com/GoogleCloudPlatform/gcloud-golang/blob/master/datastore/load.go#L253

ObjectWriter is silently failing during API outages, we should return an error if there is no object metadata can be retrieved.

        wc := NewWriter(ctx, bucket, object, nil)
    _, err := wc.Write([]byte("read/write test"))
    if err != nil {
        t.Error(err)
    }
    err = wc.Close()
    if err != nil {
        t.Error(err)
    }
    time.Sleep(time.Second)
    o, err := wc.Object() // o and err should not be both nil.

A signed URL allows a user access to a resource for a limited time.

Details at storage/docs/accesscontrol#Signed-URLs.

A Datastore query retrieves entities from the Datastore that meet a specified set of conditions.

Details at /datastore/docs/concepts/queries.

Implement entity management

Document the design of the Go gcloud library

A transaction is an operation or set of operations that is atomic—either all of the operations in the transaction occur, or none of them occur. An application can perform multiple operations and calculations in a single transaction.

Details at /datastore/docs/concepts/transactions

Handling files the Go way.

Implement continuous integration service anyone can run.

TODO(gmlewis): Calling file.DefaultBucketName in handler for each request is a silly thing to do... it should be called once in an init() function.
We shouldn't show an example to developers that promotes a bad practice.

Convert the status codes to an error in a similar way the raw generated client library is doing. NewReader silently fails for non-404 and non-2xx cases.

Implement authorization using the Service Account flow.

Bucket creation requires a project ID, we should initiate storage.Client objects with a project ID.