...thanks a lot for your suggestions. Feel free to continue the discussion, and we'll do our best to find out how your ideas can be aligned with our architecture!
On Wed, Jul 16, 2014 at 1:40 PM, Marc van Grootel <marc.van.groo...@gmail.com> wrote: > Although a plain spawn would already be helpful, I think the 28msec > implementation is much more than this, with queues and all. Surprises me > that MarkLogic doesn't have other concurrency/async mechanisms than this? > Eventually I would love to see something like the mechanisms that are > available in Clojure or Go. Some articles > http://www.infoq.com/news/2013/07/core-async and > http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html > Obviously this goes far beyond spawning a query but a man can dream right > ;-) > > > On Wed, Jul 16, 2014 at 1:08 PM, Marc van Grootel > <marc.van.groo...@gmail.com> wrote: >> >> Exactly that would've been my followup question. We cannot spawn a call in >> BaseX xquery, which is required in order to give a quick response but have >> the processing continue. >> >> I've asked this also because I think this async pattern is an important >> one for web services in general. >> >> >> >> >> On Wed, Jul 16, 2014 at 10:58 AM, Andy Bunce <bunce.a...@gmail.com> wrote: >>> >>> That marklogic link should have been: >>> http://docs.marklogic.com/xdmp:spawn >>> >>> >>> On 16 July 2014 09:55, Andy Bunce <bunce.a...@gmail.com> wrote: >>>> >>>> Hi Micheal, >>>> >>>> I think there may be a problem with the idea of using RESTXQ. My >>>> experience is that something stops requests after a minute or so, maybe it >>>> is just the browser or maybe something related on the server (Jetty maxIdle >>>> time?) >>>> >>>> And while a web-socket interface would be great, I think asynchronous >>>> execution is a core feature. >>>> >>>> eXist has util:eval-async >>>> 28msec has asynchronous-jobs >>>> Marklogic has ModuleSpawn.html >>>> >>>> >>>> /Andy >>>> >>>> >>>> On 16 July 2014 08:58, Michael Seiferle <m...@basex.org> wrote: >>>>> >>>>> Hi Marc, >>>>> >>>>> I actually think this could be done "manually" using RestXQ. >>>>> >>>>> You could maybe with something like this: >>>>> >>>>> client issues request to start a long running job: >>>>> 1) restxq/start/long-running-job -> returns job id 'Foo' >>>>> >>>>> >>>>> Every n-seconds the client asks: >>>>> 2) restxq/is-job-running?job-id=Foo >>>>> -> either redirects to restxq/is-job-running?job-id=Foo iff job >>>>> 'Foo' is still running >>>>> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >>>>> stopped running >>>>> >>>>> Obviously this kind of polling is neither an asynchronous nor the most >>>>> beautiful (yet, at the moment the only) way to do it. >>>>> >>>>> Personally I'd like to see support for >>>>> http://www.html5rocks.com/en/tutorials/websockets/basics/ Websockets, this >>>>> way RestXQ could notify the client once something is finished. >>>>> This would be true async communication and feel a lot better to deal >>>>> with. >>>>> >>>>> >>>>> More opinions on this topic are very welcome :-) >>>>> >>>>> Best >>>>> Michael >>>>> >>>>> >>>>> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >>>>> >>>>>> How would you implement an async REST pattern? I don't remember having >>>>>> seen >>>>>> anything that makes me do this using plain XQuery. Does this mean the >>>>>> only >>>>>> way to tackle this would be via Java and events maybe? >>>>>> >>>>>> I would post to a URL, this URL would accept the post and return a >>>>>> temporary URL where I can check the status of my request, then once >>>>>> it's >>>>>> ready this temp URL will redirect me to the location of the real >>>>>> resource. >>>>>> That's the gist of the async REST pattern that I would like to >>>>>> implement. >>>>>> >>>>>> What would be the best approach to experiment with this? >>>>>> >>>>>> --Marc >>>> >>>> >>> >> >> >> >> -- >> --Marc > > > > > -- > --Marc
