We don't currently support bytecode on HTTP, so that's an entirely other
conversation - one I believe that we've had before. HTTP is not something
TinkerPop tends to recommend so I personally wouldn't want to see us plow
any resources into writing more code for HTTP. We largely just have HTTP
for historical reasons going back to the days of Rexster. After some
thought I'm not against asymmetry for bytecode based requests I don't think.

As for next steps, I'd say that there needs to be a proposal for how this
gets implemented in Gremlin Server and what changes to the protocol are
needed for it to happen. As for the client-side API, I'm not sure I'm
feeling very positive about the suggestion to do g.Q() or similar syntax
because it doesn't have meaning outside of remote requests. That part can
be discussed further once we know more about how the server will allow for
interrupting traversals.





On Fri, Nov 9, 2018 at 12:28 AM kARTHIK R <k4rth...@gmail.com> wrote:

> Yes, scoping this to bytecode is a good idea. Is there any risks in trying
> to support this for HTTP requests? (Supporting sessions and scripts may
> easily bloat up the scope. so your concern there is very valid).
>
> Either way, what would be the next steps to take this forward?
>
> Karthik
>
> On Wed, Nov 7, 2018 at 9:07 AM Stephen Mallette <spmalle...@gmail.com>
> wrote:
>
> > I like the thought for explicit cancellation, but I think that before we
> > get into what that would look like or how it would work, we'd need to
> > determine the scope of what we wanted to allow cancellation of.  We have
> > scripts (both with and without a session) and we have bytecode based
> > requests. I suppose the scope could be such that we only attempted to
> > cancel bytecode based traversals which is what your proposal reads like.
> > That might be acceptable since we are trying to move folks away from
> > scripts. This would be another feature that makes bytecode a better
> choice
> > over scripts. Any thoughts on having some asymmetry there?
> >
> > On Tue, Nov 6, 2018 at 3:26 PM kARTHIK R <k4rth...@gmail.com> wrote:
> >
> > > Hi Team,
> > >
> > > This is a followup of a SO discussion[1] with Stephen where I wanted to
> > see
> > > if we can add language constructs for 1) Listing running queries 2)
> > > Cancelling a running query. Something straightforward would look like
> > this:
> > >
> > > g.query() or g.Q() -> Iterator for all running queries
> > > g.query("132" or g.Q("123") -> project a single query
> > > g.query("123").cancel() or g.Q("123").cancel() -> to cancel the query
> > >
> > > Later, the same can be extended with .profile() and other statistics
> > steps.
> > > Interested in hearing your thoughts.
> > >
> > > Karthik R
> > >
> > > [1]
> > >
> > >
> >
> https://stackoverflow.com/questions/53053463/how-do-i-list-running-gremlin-queries-how-can-i-cancel-slow-or-long-running-que
> > >
> >
>

Reply via email to