W3C home > Mailing lists > Public > xproc-dev@w3.org > August 2013

RE: New step: wait for input

From: Geert Josten <geert.josten@dayon.nl>
Date: Tue, 6 Aug 2013 09:06:01 +0200
Message-ID: <e89713261d0248a87c17ed53cb6aa7e9@mail.gmail.com>
To: James Fuller <jim@webcomposite.com>, Norman Walsh <ndw@nwalsh.com>
Cc: XProc Dev <xproc-dev@w3.org>
Hi,

A wait for update doesn't sounds like the same as a wait for input to me.
Wait for input is really about new information being submitted in an
asynchronous way. I could imagine you would have special sources/pipes
which would allow connecting to stdin, or some kind of 'input stream' or
queue on which new input can arrive in delayed fashion.

I also loved the idea of continuations in Cocoon, if anyone is familiar
with those. It allowed interrupting a server-side flow to do an
intermittent round-trip to the end-user, to ask for additional input for
instance. Not sure how that could fit into XProc, but that would surely be
very cool.. ;-)

Kind regards,
Geert

> -----Oorspronkelijk bericht-----
> Van: James Fuller [mailto:jim@webcomposite.com]
> Verzonden: dinsdag 6 augustus 2013 8:50
> Aan: Norman Walsh
> CC: XProc Dev
> Onderwerp: Re: New step: wait for input
>
> On 5 August 2013 18:38, Norman Walsh <ndw@nwalsh.com> wrote:
> > Ari's Balisage symposium talk highlights the need for a step that will
wait
> > for user input. I wonder if
> >
> >   <p:wait-for-update href="someURI"/>
>
> and at xprocathon did we not have someone ask for a wait-for-input ?
>
> how far would we go, eg. should we consider a compound step as in the
> example below ?
>
> <p:wait>
>   <p:xpath-context/>
>   <p:variable/>
>   <p:option name="check-every"/>
>   <p:option name="timeout"/>
>   <p:when test="">
>    <!- sub pipeline -//>
>   </p:when>
>   <p:otherwise>
>    <!- sub pipeline -//>
>   </p:otherwise>
> </p:wait>
>
> this would generalize the step but unsure how we would handle
> detecting state change.
>
> J
>
> > would do the trick. The proposed semantics are that it waits until
> someURI has
> > changed. For file: URIs, this is obvious, but I think it could be made
to
> work
> > for HTTP URIs as well, at least those where the server returns a last-
> modified
> > or etag header.
> >
> >                                         Be seeing you,
> >                                           norm
> >
> > --
> > Norman Walsh
> > Lead Engineer
> > MarkLogic Corporation
> > Phone: +1 512 761 6676
> > www.marklogic.com
Received on Tuesday, 6 August 2013 07:06:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:11 UTC