Re: [orion-dev] Operations and cancellation support...

["Simon Kaegi" <Simon_Kaegi@xxxxxxxxxx>]

For the HTTP Status Code for a cancel request... if you could have only one return code it should be a 202. A 200 would only be valid if the state change occurred immediately. I think it happens to be immediate in the Orion server-side cancel case but would have to look at the code to be sure.

For the UI bit... The "Operations page" is showing long-running tasks associated with Orion's server-side back-end. Part of the reason that it is not in your face is that it's not quite the right abstraction for client-side work -- it's not a general purpose "progress" view that other services can contribute it to at the moment. What I would like here is an operations view that would call the various plugins that provide an "operations" endpoint to collate all of the status information for that user in one place (essentially collate server-side long running task status).

The issue bring about the kinds of work we track is interesting. There is something we need here that we do not have currently -- a client-side Task or work-in-progress API (that among other things supports cancellation and progress but also the ability to get the current status). When we had originally done this work I had hoped that Promises were a sufficient abstraction for progress reporting and cancellation however I am now quite convinced that was wishful thinking. For those operations in the client that take a long time we should actually pass back a representation of work in progress that can be interacted with as opposed to just waited on.

If you're interested in noodling away on the task problem problem we can open a new bug report as it's something that would need work to integrate properly. If you for now just want to add server-side task to the node implementation -- go for it. Unless there's a strong reason I would trend to use the existing Java Server's approach but open to ideas.

-Simon


Remy Suen ---2016/11/25 08:22:52 AM---Hi everyone, [I might be sending this a second time...but I think iOS just deleted

From: Remy Suen <remy.suen@xxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 2016/11/25 08:22 AM
Subject: [orion-dev] Operations and cancellation support...
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

Hi everyone,

[I might be sending this a second time...but I think iOS just deleted
my first draft so maybe this is the first time I'm sending this.]

I spent the morning today looking at adding cancellation support to
Node [1] (before you ask, my students were taking tests today so I
didn't have to teach any classes in the morning :)). I noticed
cancellation support was added into the Java server a few years back
[2]. The reason I wanted this implemented was because `git log` is
almost unusable in Node when performed on a file [3].

Now the actual implementation is not too bad, we just need to add PUT
support into the Node server's tasks service so that's pretty easy and
straightforward. However, I noticed that only operations deemed as
non-temporary could be canceled because those were the only ones that
were visible in the operations page. And as far as I know, please feel
free to prove me wrong as I'm still new to all of this, the only way
to cancel something is by canceling it in the operations page. If
that's the case, then that just seems wrong to me.

Just because an operation is a "temporary" operation (I'm not even
sure what criteria we are using for this, I guess it's up to the
service provider) shouldn't mean that that operation is
non-cancelable. I think all operations should be shown in the
operations page. Or, y'know, we could add some states like what we
have in Eclipse with system jobs, regular Joe jobs, and user jobs and
the user could filter the operations page as they please. Then the
user could just set filters and see whatever they want to see.

------------------

I was wondering if there was any discussion around surfacing
cancellation support more clearly to the user after an operation has
started. The operations page is kind of hidden of to the side so the
fact that an operation can be cancelled is kind of hidden to the user
in my opinion. Admittedly, unless you've opened that page in a new
tab, opening the operations page kind of throws your entire context
away (since you're no longer in an editor). So, maybe the idea here is
that you're usually not thinking about cancelling an operation when
you look at the operations page because whatever operation was
previously running has effectively been "cancelled" by you having
"abandoned" your context...I guess?

------------------

As an aside, when a task is canceled, should a 200 be returned or a
202? I feel like a 202 makes more sense since the service cannot
guarantee when the cancel request will be honoured...if it ever even
does. Do we have any guidelines in Orion as to when to use a 200 and
when to use a 202?

Thank you for your time.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=508095

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=397899

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=507334

Regards,
Remy
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev