Re: Constant Inputs during Iteration

Erik Bruchez wrote:
> 
> Alex,
> 
>  >> o Stores a document into eXist as a step of the iteration
>  >>
>  >> o Retrieves the updated version from eXist using the eXist REST API
>  >>   during the next iteration, with an HTTP URI like:
>  >>
>  >>   http://example.org/exist/rest/db/latest.xml
>  >
>  > It isn't the URI label to document that remains constant.  It is the
>  > input mapping that remains constant.
> 
> Sorry I can't make sense of this sentence.

In the pipeline, there are documents that flow between steps or to into
inputs.  The question is about whether *that* document is constant and
not whether the URI to document mapping is constant.

>  >> Also, requiring all static URIs to be constant requires the
>  >> implementation to use a sort of cache, even for "file:" URIs. I am not
>  >> sure that this is necessary.
>  >
>  > The consequence of not having this is that during iteration the
>  > results from two different applications of the subp-ipeline could
>  > inexplicable be different unless you knew that "the world changed"
>  > during execution.  Given that execution times will generally be
>  > short, this is really going to confuse the user.
> 
> Debatable. With my eXist use case, the user has updated the HTTP
> resource and can reasonably expect the update to be taken into
> account. I would argue that making the document constant in this case
> is confusing to the user.

You don't have the document that is in eXist.  You have to go
retrieve that document.  If your pipeline implementation determine that
there is a static reference to a document and pre-fetches that or
some other kind of optimization, then it will have the wrong
version of the document.

In this case, you're talking about a side-effect to a document
that you've caused.  I think we should have the model where you
*need* to retrieve that document again to see the side-effect.
I don't think that means that the input that has previously
be computed changes to reflect that side-effect.

> 
>  > If you want to "retrieve" a document during execution of a
>  > sub-pipline as part of an iteration, you should use some kind of
>  > "load" step to ensure that you have the most current version of the
>  > resource.  That allows the intent of the author to be explicitly
>  > encoded in the pipeline.
> 
> Debatable too. Why should I use a "load" step in this REST world
> instead of using a regular HTTP URI that follows HTTP semantics
> (including caching semantics!)?
> 
> I think that your suggestion to use such as step leads to a much
> "madness" as my own above ;-)

Because you need to recognize you have a side-effect and handle that.

The case the worries me is where you retrieve a resource via URI
as an input and it changes during execution but you don't want the
change.  You now have no control over that because the input has
been fetch automatically and you can't prevent that.

Received on Monday, 2 October 2006 17:34:34 UTC