I don't know of any clients that don't use websockets. The HTTP stuff is mostly for curl like requests afaik. At least to me, I don't think we care about tracking this "agent" over raw HTTP requests. I would imagine that having it sent once makes the most sense in any event so putting it on the handshake seems right, but i assume the server would need to keep that information in its context for the connection somehow so that it could be used for logging in relation to a particular query.
On Mon, Oct 3, 2022 at 9:37 PM Ken Hu <[email protected]> wrote: > Hi Stephen, > > Thanks for your response. > > After giving it some more thought, I think that I want to modify the > proposal. Rather than using the current "userAgent" RequestOption argument, > I think it might make more sense instead to add a custom User-Agent header > to the WebSocket handshake. This should prevent breaking most users since > it doesn't seem to exist in any of the clients. It also allows for it to be > sent just once during the handshake instead of per request. One downside > would be that the server won't get this same information if the client is > connecting via HTTP, but given that most GLVs seem to use WebSockets this > may be a minor issue. > > Any thoughts on this change? Is the lack of standardization for HTTP-based > clients going to be an issue? > > Thanks, > Ken > > On Fri, Sep 30, 2022 at 4:11 AM Stephen Mallette <[email protected]> > wrote: > > > Thanks for the proposal Ken. > > > > > To allow this change in the 3.5-dev branch, we would probably want to > > prevent breaking current users of the "userAgent" header. > > > > While we aren't losing any current userAgent values by appending to the > > end, I think that we're still potentially establishing a breaking change > as > > the value that arrives to a server in 3.5.5 won't be the same as the one > > that arrives from 3.5.4. > > > > That said, I think that tiny break is acceptable as I believe this > feature > > to be not widely used or known by anyone. If there are any objections to > > this change for 3.5.5, I'd say it should go in 3.6.2 as providers are > still > > consuming that line and the impact lessened. > > > > > > > > On Thu, Sep 29, 2022 at 6:36 PM Ken Hu <[email protected]> > > wrote: > > > > > Hi Divij, > > > > > > Thanks for the response. My thoughts are below. > > > > > > 1. Is "space" a good delimiter between fields? > > > In my opinion, space should work as a delimiter for these fields as > long > > as > > > we ensure that the fields the driver creates don't contain any spaces. > > > Though any other delimiter would work fine. I chose space since that is > > > what is used in HTTP. Did you have a different delimiter in mind? > > > > > > 2. Are the individual fields nullable/optional? > > > Yes, they are nullable/optional with the exception of [GLV > > Name]/[Version]. > > > If a particular field can't be populated then we will probably just > add a > > > value like NotApplicable. > > > > > > 3. Would we have any client & server side validation to assert the > > > structure of UserAgent string? > > > The client side would be implemented in a way that all the GLVs would > > > produce a string with the same structure. There is unlikely to be > > > validation on the server side for now although that should be > relatively > > > straightforward to add. > > > > > > 4. Would users have concern with sharing the details of their > environment > > > due to privacy reasons? > > > This is possible, however, we wouldn't be collecting anything > personally > > > identifiable. We could also add in a connection option that would > disable > > > this feature. > > > > > > 5. Do all languages have methods that provide details of the runtime > > > environment? Is it structured similarly across languages? > > > All the current languages have the ability to gather information for > the > > > proposed fields with the possible exception of Go which can't easily > > report > > > OS details. There are some minor differences that would need to be > sorted > > > out. For example, some OS/runtimes report the same 64bit architecture > as > > > amd64 or x86_64. > > > > > > Let me know if you have any further questions. > > > > > > Thanks, > > > Ken > > > > > > On Thu, Sep 29, 2022 at 4:35 AM Divij Vaidya <[email protected]> > > > wrote: > > > > > > > Hey Ken > > > > > > > > Thank you for the proposal. I have a few questions and would solicit > > your > > > > thoughts on these. > > > > > > > > 1. Is "space" a good delimiter between fields? > > > > 2. Are the individual fields nullable/optional? > > > > 3. Would we have any client & server side validation to assert the > > > > structure of UserAgent string? > > > > 4. Would users have concern with sharing the details of their > > > > environment due to privacy reasons? > > > > 5. Do all languages have methods that provide details of the runtime > > > > environment? Is it structured similarly across languages? > > > > > > > > -- > > > > Divij Vaidya > > > > > > > > > > > > > > > > On Thu, Sep 29, 2022 at 2:57 AM Ken Hu <[email protected] > > > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > With regard to TINKERPOP-2480, I propose that we formalize the > usage > > of > > > > the > > > > > "userAgent" header in TinkerPop. Currently, this is a user-supplied > > > value > > > > > that can be any custom string. Because this header is often > missing, > > it > > > > > can't be used to determine which GLV is being used to connect to > the > > > > > server. Instead, the GLVs should automatically add a value for this > > > > header. > > > > > > > > > > The proposed format would be as follows: > > > > > [Application Name] [GLV Name]/[Version] [Language Runtime Version] > > > > > [OS]/[Version] [CPU Architecture] [User-Supplied Extension] > > > > > > > > > > Spaces would be removed from each part (such as Application Name) > in > > > > order > > > > > to make it easier to parse the string. > > > > > > > > > > To allow this change in the 3.5-dev branch, we would probably want > to > > > > > prevent breaking current users of the "userAgent" header. To > > accomplish > > > > > this, I propose that we append any user-supplied information to the > > end > > > > of > > > > > the string (it becomes the User-Supplied Extension). > > > > > > > > > > Let's walk through a simple example. > > > > > > > > > > Given this sample code: > > > > > client.submit("g.V().count()", > > > > > > > > > RequestOptions.build().userAgent("myUserSuppliedValue").create()).all(); > > > > > > > > > > Currently, the args for RequestMessage would contain: > > > > > userAgent=myUserSuppliedValue > > > > > > > > > > The proposed RequestMessage, however, would contain: > > > > > userAgent=TestApplication gremlin-driver/3.5.4 11.0.16 MacOSX/12.6 > > > x86_64 > > > > > myUserSuppliedValue > > > > > > > > > > Any comments or suggestions to this proposal would be appreciated. > > > > > > > > > > Thanks, > > > > > Ken > > > > > > > > > > > > > > >
