Community
Participate
Working Groups
Even usually short operations may last longer. This may be caused by a slow connection to a Git repo or problems with the net etc. We could run all operations as tasks, but there is another solution we already use for git operations. So if an operation is quick, we return immediately (200). If for any reason it is longer it becomes a task and 201 is returned. I think we should consider making this mechanism more generic as part of our .4 progress service work.
An example for necessity for moving operations that didn't require tasks until now is Bug 361006.
One small change I suggest: when the operation cannot complete immediately it should return 202 Accepted. Some links: http://wiki.eclipse.org/Orion/Server_API#Progress_reporting http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3
(In reply to comment #0) > [...] there is another solution we already use for git > operations. So if an operation is quick, we return immediately (200). If for any > reason it is longer it becomes a task and 201 is returned. Afaik, this approach is only implemented when requesting Git Log. If it takes longer then expected 202 (HttpServletResponse.SC_ACCEPTED) is returned as John suggested in the last comment.
(In reply to comment #2) > One small change I suggest: when the operation cannot complete immediately it > should return 202 Accepted. Some links: > > http://wiki.eclipse.org/Orion/Server_API#Progress_reporting > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 Yeah, I meant Accepted (202). It would be cool, if we could use it transparently like we already do with authentication (at least server side, on the client side we still need to add the magic 'handle....AuthenticationError' line).
We have to be careful with creating tasks for GET requests[1]. This doesn't sound RESTy[2]. [1] bug 365534 [2] See last paragraph of http://books.google.com/books?id=XUaErakHsoAC&lpg=PP1&pg=PA229#v=onepage&q&f=false
Everything is migrated now.
