[32/50] [abbrv] tinkerpop git commit: update index.asciidoc

[sp...@apache.org]

update index.asciidoc

Add design doc for reference based object model

Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/ba915458
Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/ba915458
Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/ba915458

Branch: refs/heads/tp33
Commit: ba915458a3d4121a55d563dfc8267417574c8f94
Parents: ead0eda
Author: Ashwini Singh <30...@users.noreply.github.com>
Authored: Thu Mar 22 15:42:43 2018 -0700
Committer: GitHub <no...@github.com>
Committed: Thu Mar 22 15:42:43 2018 -0700

----------------------------------------------------------------------
 docs/src/dev/future/index.asciidoc | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/ba915458/docs/src/dev/future/index.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/future/index.asciidoc b/docs/src/dev/future/index.asciidoc
index d37f3e1..9d3c49e 100644
--- a/docs/src/dev/future/index.asciidoc
+++ b/docs/src/dev/future/index.asciidoc
@@ -152,8 +152,26 @@ essentially build a subgraph which is merged into the primary graph. That subgra
 Build it locally then submit it remotely and have the server sort out the merging. It's perhaps the most natural way
 to load data. With "Gremlinito" you then get the added power of being able to traverse a local subgraph.
 
+
+== Uniform object model for GraphSON response for client drivers
+On TINKERPOP-1909, it was suggested that we are going to use refence (id/label) based object model. And, the direction is
+move towards more tidy object model contracts going forward. Reference model definitely provides big performance improvements
+especially with multi-property vertices/edges.  One thing that we can consider is to provide a configurable object 
+model. Enabling users to configure the object model (OutputFormat) as server settings (Exposing server setting is
+being discussed here TINKERPOP-1636). There will three types of output format. 
+
+* Reference: includes id and label 
+
+* GraphSONCompact: object reference along with properties 
+
+* GraphSON: object reference, properties and edge details(inE/outE). 
+=== Comments
+This will enable the clients model based on their needs and avoid multiple query if they are sure what is expected 
+from a gremlin query. If we need more details like edges/property as part of response, we can override the server 
+configuration as part of the gremlin request arguments as hint. 
+
 == Testing Framework
 
 Consider a testing framework based on the Gherkin tests from 3.x and a `gremlin-test` parent module for all the test
 framework modules that will potentially be needed. In 3.x, we found situation where having test modules beyond
-`gremlin-test` would have been helpful, so a parent module that held all those would probably be smart.
\ No newline at end of file
+`gremlin-test` would have been helpful, so a parent module that held all those would probably be smart.