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 <divijvaidy...@gmail.com>
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 <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
> >
>
