Sometimes, I whish I could think faster.

The fact request can be pipelined like this -I mean, by taking care of the
fact replies are not necessarly returned in requests order- doesn't not
mean that clients have to choose the FIDs. This would also work if FIDs
are choosen by the server (and even better because the client would not
have to take care of the order).

So unless Russ is right and that the fact FIDS are choosen by the client has
been decided arbitrarily ... I still have no answer to my question.

Phil;

Philippe Anel a écrit :
> Ok I agree ... as long as you don't expect the replies to be returned
> in the same order as the requests, requests can be pipelined.
>
> Therefore, now it makes sense to have FIDs chosen by the client.
>
> Thank you.
>
>>
>> Well you may have a point, but why not
>>
>> 1. send: open, fid, file
>> 2. wait for reply to 1.
>> 3. send read, fid, args
>> 4. send read, fid, args
>> 5. wait for either...
>> 6. wait for remaining?
>>
>> At that point you're still pipelining, and since you're reading
>> presumably into separate buffers, or different locations in the same
>> buffer, who cares about the order?
>>
>>
>>
>>     Because all transactions are tagged ... this wouldn't break
>>     9P. However, this doesn't work as expected.
>>
>>
>> Depends on what's expected :-)
>>
>>
>>     That's why I think 9P was not designed to allow this. But
>>     maybe I'm wrong.
>>
>>
>>
>> It's probably designed to allow what I just said, you can sequence
>> some operations, but then things that don't need to be sequenced
>> could be pipelined.
>>
>> Different servers may behave differently, 9P makes no guarantee AFAIK.
>>
>> Dave
>>
>>
>>     Phil;
>>
>>
>>
>>
>>
>> --
>> - Passage Matthew 5:37:
>>    But let your communication be, Yea, yea; Nay, nay: for whatsoever
>> is more than these cometh of evil.
>
>
>