Github user PommeVerte commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/291#issuecomment-211433503
Hey Mike. Sounds fair enough. I wasn't pointing fingers, just wanted to
understand the thought process a bit better.
Just to explicit what I meant by the difference between prepending and
adding. The payload is constructed of a `wrapper` which is basically a `byte`
and a `mimetype` at this point for binary payloads. And a `message` to be
deserialized (via `GraphSONMessageSerializer`, `GryoMessageSerializer`, etc.).
Prepending is basically adding the mechanism to the `wrapper`.
Adding would be including it in the `message` as an argument. Along side
the `sasl` credential argument for example (or some other variation)
The difference here is that with the curent implementation, existing
drivers will need to be upgraded to support this feature change in the payload,
along the lines of the changes you made in this PR on the Java Driver.
The first point here is that this can be an issue with drivers that
separate the `wrapper` building logic from the `message` building. ie: the
`wrapper` is always built the same way and reused for all operations. Adding
the mechanism for _only_ the authentication `message` becomes a special use
case in the `wrapper`. Depending on the implementation this can either get
ugly, or be less trivial than expected. (`PHP`, `javascript` and `python`
drivers fall in this category)
The second point is that if the mechanism were included as a `message`
argument instead, then most drivers out there either already support this
feature or have mechanisms in place to extend authentication `message`
building. So we basically provide the feature keys in hand for users of those
drivers. And if the drivers really have no support for what was just mentioned,
it's a trivial upgrade.
I tried to keep this clear but it's not one of my fortes. Let me know if it
wasn't clear, or if there's some conflicting logic in implementing this in the
message rather than the wrapper.
Cheers.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---