Hi everyone, I'm working on properties on elements ( https://issues.apache.org/jira/browse/TINKERPOP-2824). I found HaltedTraverserStrategy` in `TraverserIterator` that does about the same, converting Elements to detached or references. Tests use reference Elements, and detached is default for production. GLV's possibly can override strategy to get different results. My implementation of `DetachedStrategy` is to add the last step to the traversal which modifies the result, so, technically g.V() becomes g.V().[DetachStep]. Also default server configuration adds ReferenceElementStrategy https://github.com/apache/tinkerpop/blob/master/gremlin-server/scripts/empty-sample.groovy#L45 to each traversal.
1. So I end up with 3 ways to cut properties and I'm not sure how to handle it. What options would you suggest? My proposal is to always have some detachment strategy in server configuration and add `DetachedStrategy` to allow users the flexibility to customize the result. `HaltedTraverserStrategy` can be marked deprecated as it handles only bytecode traversal, but not used for scripts. Another side of the problem is the need to detach custom vertex implementations like `TinkerVertex`. 2. How to handle more than one `DetachedStrategy`? For example one can be set in Gremlin Server configuration and other in user traversal. Options: a) apply all. Each successive DetachStrategy becomes more restrictive. b) apply only last one. Use case: there are default server configurations to return only some properties and the user can override it for each request. I think both options make sense, but I prefer the second. 3. Another question is whether or not to show `DetachElementStep` in the response for profiling requests like `g.V().profile()`. Users may be confused at the appearance of a step that they did not add, but on the other hand it will be an explanation why there are no properties in the response. Is it better to hide `DetachElementStep` or vice versa? Thanks, Valentyn
