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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to