Hearing your findings on the id issue would be great - M9 should have sorted those out. Confirmation on that would be appreciated.
On Tue, May 5, 2015 at 9:03 AM, Dylan Millikin <[email protected]> wrote: > Great, > > I'll probably have more feedback once I get a proper go at the TP3 stack. > I'm mostly waiting for Titan to build against M9 because of the ID > lossiness. > > On Mon, May 4, 2015 at 4:26 PM, Stephen Mallette <[email protected]> > wrote: > > > Thanks for the fast feedback - I've merged this change back to master - > it > > will be available for 3.0.0.M9 > > > > On Mon, May 4, 2015 at 2:07 PM, Dylan Millikin <[email protected] > > > > wrote: > > > > > Same, This is an easy change on the driver end and makes more sense as > > > well. > > > > > > On Mon, May 4, 2015 at 7:37 AM, Stephen Mallette <[email protected] > > > > > wrote: > > > > > > > It occurred to me that the Gremlin Server protocol hasn't changed in > > any > > > > way in months. A good thing, perhaps, but it also worried me a > little, > > > in > > > > that on the other hand the reason it may not have changed is because > it > > > > hasn't been paid enough attention. In giving it another review, I > > found > > > > that I was quickly reminded of an annoying element of it - the > "message > > > > terminator". > > > > > > > > Since Gremlin Server streams results back, the protocol need a way to > > > > express that the stream was "done". I'd implemented this as a > > > terminating > > > > message with a status code 299. This approach had the effect of > > marking > > > > the stream as "done" but came with the expense of an extra message > for > > > > every request. If I had n requests which generated a stream of s > > > response > > > > messages, i'd construct (n * 2) + s response messages to get all n > > > requests > > > > met. I must have grown smarter in the last few months because it > only > > > took > > > > a few keystrokes to alter the code to get rid of the terminator > leaving > > > us > > > > with n + s response messages which is an obvious improvement. > > > > > > > > To accomplish this, I introduced these changes: > > > > > > > > 1. Dropped status code 299 > > > > 2. Added status codes 204 (NO_CONTENT) and 206 (PARTIAL_CONTENT) > > > > 3. On a successful request with streaming results, the server will > > return > > > > 206 to represent that there are more results to be returned in the > > > stream. > > > > Those results will continue until 200 (SUCCESS) is returned. A > > successful > > > > result with no streaming (e.g. 1 result in an iterator) will just > > return > > > a > > > > 200. > > > > 4. All other status codes outside of 206, including the new 204 > (which > > is > > > > returned for things like an empty iterator) represent terminating > > > > conditions for the stream. > > > > > > > > I have this work in a branch at the moment, but would like to move it > > to > > > > master in time for M9. As this was a breaking change for the various > > > > clients out there (gremlin-js, aiogremlin, etc), I thought I'd post > > here > > > > first for comments before introducing it. > > > > > > > > Thanks, > > > > > > > > Stephen > > > > > > > > > >
