Re: [PR] Option to force the message to be sent as string instead of bytecode [tinkerpop]

["Cole-Greer (via GitHub)" <gi...@apache.org>]

Cole-Greer commented on PR #2314:
URL: https://github.com/apache/tinkerpop/pull/2314#issuecomment-1788329164

   Thanks @divad1196, I agree that a brief first time contributors guide somewhere such as the README would be useful. I will try to find some time assemble something there soon. The official contributing guidelines can be found [here](https://tinkerpop.apache.org/docs/current/dev/developer/#_contributing_code_changes), although the discoverability and accessibility could likely be improved. As for your question about getting changes into 3.6.6 and 3.7.1, it comes from the way we merge PR's. When a PR gets accepted into 3.6-dev, the committer who merges it in will also merge that change up to 3.7-dev and master to ensure that it also ends up in newer branches. We always merge changes up the branches, but not down.
   
   As for your changes here, I took a closer look today and I think there is more consideration needed before we can proceed further. The first question is if the "script-only" mode would bring benefit to any systems beyond CosmosDB. While I do have some sympathy regarding incompatibilities, if CosmosDB is the only outlier here, I would much rather see them unify behind the standard TinkerPop system rather than fracture our drivers with additional configurations. One of my long term goals for TinkerPop would be to have the number of configurations for drivers and servers reduced significantly. Additionally, I really want to reduce the differentiation between all of our drivers. We currently have too many features which are exclusive to only a few of our drivers. For that reason, if we accept this change, it would require us to prioritize adding similar capabilities to the other drivers (Java, go, .net, js) sometime in the near future.
   
   I think this is a decision which would need a [dev-list](mailto:dev@tinkerpop.apache.org) discussion before proceeding in order to decide if this is a direction the community would like to move in. If the community does want to accept these changes, some tests would need to be written for this PR to ensure that the driver remains compatible with gremlin-server with `bytecode_allowed=False`.
   
   Overall I think it is an interesting change, and it definitely looks valuable for CosmosDB users, but I'm not sure if extending the drivers to support outdated systems is the right direction for TinkerPop at this time.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org