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 <30875507+ashwini...@users.noreply.github.com>
Authored: Thu Mar 22 15:42:43 2018 -0700
Committer: GitHub <nore...@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(-)

diff --git a/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.

Reply via email to