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 <k...@bitquilltech.com.invalid>
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
>

Reply via email to