On Mar 28, 2008, at 14:01 , Peter Boncz wrote:
> Hi Maurice,
>
> - what you want *really* is XQueryP, but we do not have resources to
> give you
> that. The fact that we use the result sequence to pass on the update
> tape
> actually makes it difficult to give back a result.
> - if you send tw
Hi Maurice,
- what you want *really* is XQueryP, but we do not have resources to give you
that. The fact that we use the result sequence to pass on the update tape
actually makes it difficult to give back a result.
- if you send two asynchronous requests, there is no guarantee that one is
executed
Peter Boncz wrote:
> Hi Maurice,
>
> That is not possible.. without adding extensions such as proposed in XQueryP
> or
> XQuery-Bang.
>
> Why is it that running the update followed by a query is not acceptable?
>
Running an update followed by a query is acceptable. My point is that
the update
On Mar 28, 2008, at 11:53 , Peter Boncz wrote:
> Hi Maurice,
>
> That is not possible.. without adding extensions such as proposed in
> XQueryP or
> XQuery-Bang.
>
> Why is it that running the update followed by a query is not
> acceptable?
>
> Another idea is to use fn:put() in the update, an
Hi Maurice,
That is not possible.. without adding extensions such as proposed in XQueryP or
XQuery-Bang.
Why is it that running the update followed by a query is not acceptable?
Another idea is to use fn:put() in the update, and then just a HTTP GET to get
the XML result out. That is still a si
Ying Zhang wrote:
> Hi Maurice,
>
> Stupid me. I only described how the current XRPC implementation is,
> but forgot to mention the ongoing work.
>
> On Mar 28, 2008, at 09:35 , Keulen, M. van (Maurice) wrote:
>> Hi Peter,
>>
>> Does it also mean that if I send a stream of messages to one server
Hi Maurice,
Stupid me. I only described how the current XRPC implementation is,
but forgot to mention the ongoing work.
On Mar 28, 2008, at 09:35 , Keulen, M. van (Maurice) wrote:
> Hi Peter,
>
> Does it also mean that if I send a stream of messages to one server
> that all carry the same re
Hi Peter,
Does it also mean that if I send a stream of messages to one server that
all carry the same request-ID without waiting for a result of a message
before sending out the next, that all are handled in the correct order
and each is handled after completion of the previous one? In that cas
