JSON is comfortable and easy, but something like this makes sense to
me. This idea could be easily extended to to request/response messages
as well. For example, the desired op ('eval', 'bytecode', 'close'
etc.) could be represented with a 4 bit group, etc. etc. This would
allow driver authors to
[
https://issues.apache.org/jira/browse/TINKERPOP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217150#comment-16217150
]
ASF GitHub Bot commented on TINKERPOP-1801:
---
Github user artem-aliev commented on the issue:
Github user artem-aliev commented on the issue:
https://github.com/apache/tinkerpop/pull/734
Something strange happened, during rebases. I'll fix.
---
[
https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216911#comment-16216911
]
ASF GitHub Bot commented on TINKERPOP-1752:
---
Github user spmallette commented on the issue:
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/712
Looks like traversal strategy classes have their own serialization
forms
```json
{
"@type": "g:Bytecode",
"@value": {
"source":
Hi,
I wanted to bring up the possibility to include a specific (as in
non-generic) serialization formal for Graph data. I didn't want to
bump the last
dev discussion on serialization formats
