Where do we set the user agent in the request?

[jgeewax]

Do we set it as gcloud-java/[version] ?

[aozarov]

It is now hard-coded as "gcloud-java".

Adding the version would be nice and as we already include it in the jar's manifest that would not be hard. We should probably have this logic for getting the "application name" in the core module
as a utility or as part of the ServiceOptions.

Note, setting it for the datastore would be a little tricky as we don't use the apiary client directly but rather use the datastore-protobuf client which does not seem to expose it. /cc @pcostell

[circy9]

Is it possible to set a header in datastore calls?
A separate question, do you have access to the headers of the incoming HTTP requests?

For example, a user makes a HTTP request, say ListMyContacts, to the app and then the app makes a bunch of datastore call to handle the HTTP request. I am interested in extracting headers from this user issued HTTP request.

[aozarov]

I think we will be able to set it also in the Datastore calls, but I cc @pcostell for some advice (so we will do it the right way).

The app which uses gcloud-java could be a stand-alone, servlet, or anything else. The app does not pass any context information to the gcloud-java api and therefore we are not aware if a call is triggered by some HTTP request or have any information about it.

[aozarov]

@mziccard Do you want to take care of this? Ajay has already few outstanding issues to take care of.

[pcostell]

It looks like you could do this either by continuing to use the Datastore clients and override RemoteRpc.java (which then gets passed in when you create a Datastore), or you could just stop using the client (may be better long term since you replicate a lot of the work anyways for the other APIs).

[aozarov]

I don't think we can override RemoteRpc.java as it is package protected.

Right, we could avoid using the Datastore protobuf client and instead use the apiary client directly but I wonder if it is worth the effort considering the future migration to gRPC. Also, do you have this client available for v1beta3?

/cc @ajkannan

[pcostell]

Ah good point -- we could probably add some extra handling to push headers onto the call.

If you are planning a grpc migration soon you could do that too -- v1beta3 does work with grpc.

We have a v1beta3 implementation but it hasn't made it onto github yet. If you ping me privately I can send you a link.

[ajkannan]

Looking at what we use within the Datastore client, I think we could decouple gcloud-java from the Datastore client without too much effort now and then maintain it without too much additional work. It looks like we would only need to replace the functionality of the client's RemoteRpc.java, DatastoreFactory.java, Datastore.java, and DatastoreOptions.java. Most of the work in the client's DatastoreHelper.java is done by our gcloud-java-core module.

[ajkannan]

I spent some time trying to use the apiary client, and that necessitated a lot of superficial changes that would be more trouble than its worth, especially when merging in the v1beta3 branch. I can look into using gRPC after the v1beta3 branch is merged in and we're ready to migrate to gRPC.

[aozarov]

I think we should consider #307 as a fix for this issue. I opened a separate issue, #308, for just Datastore.