Adding those kinds of details was the reason we had the
ResponseStatus.attributes Map. I can really only speak for the java driver
as I only know that one really well (we might need other TinkerPop experts
to chime in for python, .net and c#).  The java driver doesn't really
present ways to get that information easily under usage that doesn't deal
directly with RequestMessage directly (which people typically don't do).
Another thing to think about is that since a single request might return
multiple ResponseMessage instances you might not want to return that kind
of data on every response - maybe just to be returned on the first (or last
message) and then we somehow preserve that information and make it
accessible on the result somehow....we sorta have some kinda of precedent
for that with side-effect data generated by bytecode based traversals - we
can probably build in something similar for this sort of thing.

I also toyed with the idea of using ping/pong websocket messages to carry
general information about the server to the client. Not sure if any of the
metadata you want to send back would fit in there, but that could be
another option.

Does any of that sound helpful?

On Fri, Feb 23, 2018 at 3:41 PM, Ashwini Singh <> wrote:

> Hi All,
> We are working on to expose metadata as part of gremlin to response to
> client. The metadata is simply a property bag to provide special
> message/hints to the client. But currently client libraries strip off
> everything and only return the data to the client.
> Specifically, We want to expose details like Request Charge, Rate
> limiting/Retry policy details etc. In the other scenarios in Cosmos DB we
> provide these details to the client is through response headers. We did
> some investigation around this and one of the options is expose these is
> through response attributes. Gremlin Server can add metadata as part of
> gremlin response attributes (For example, set the property bag on
> ResponseStatus.Attributes for Gremlin.Net) that can be serialized by the
> client drivers to the clients.
> We  would like to learn more if there are precedence around this and if
> there are any recommended ways to achieve this in Gremlin protocol and
> client drivers.
> Thanks a lot,
> Ashwini Singh
> Software Engineer @ Azure Cosmos DB

Reply via email to