Hello,
> Some requirements,
> * You should be able to pipeline all operations.
Done I do believe. The only exception is the reorder op, which requires
the version# to be ready. Actually I could fix that so it is chosen by
the client, if that is a problem.
> * Failures of one message in the pipeline should not invalidate
> remaining operations.
Need to rephrase this requirement, as it stands it's garbage. A delete
of an object which didn't get inserted will always fail for instance
(silly case, but you get the point I'm sure).
However the only operation which _intentionally_ fails on previous
failures is the swap one, which I'm not 100% sure on. Otherwise unless
you are in a nonsensical situation it should be fine.
> Here is a bunch of examples that should all work in any situation.
>
> The object will always start with the following orders,
> <Order A>
> <Order B>
> <Order C>
>
> Task 1:
>
> The client wants to do the following,
> Delete <Order C>
> Insert <Order D> after <Order A>
> Delete <Order B>
>
> Expected result
> <Order A>
> <Order D>
Send Delete <C>
Send Insert <D> before <B>
Send Delete <B>
Possible results:
- Delete <C> fails:
Other orders in pipeline complete as expected
- Insert Fails:
Other orders complete as expected
- Delete <B> fails:
Last order.
So, I think this works as well as can be expected.
> Task 2:
>
> The client wants to do the following,
> Delete <Order A> (which will fail)
> Delete <Order B>
>
> Expected result
> <Order A>
> <Order C>
Send Delete <A>
Send Delete <B>
Failure has no effect on later messages, so it works.
> Task 3:
>
> The client wants to do the following,
> Delete <Order B> (which will fail)
> Delete <Order C>
>
> Expected result
> <Order A>
> <Order B>
As Task 2. No problem.
> Task 4:
>
> The client wants to do the following,
> Insert <Order D> after <Order A>
> Insert <Order E> after <Order C>
> Insert <Order F> before <Order E>
>
> Expected result
> <Order A>
> <Order D>
> <Order B>
> <Order C>
> <Order F>
> <Order E>
Okay - this one has the problem...
Insert <D> before <A>
Insert <E> before end (append)
-> Insert <F> before <E>
Can't do that in this order, as we don't have the full ID of <E>.
Alternative is (if client can reorder):
Insert <D> before <A>
Insert <F> before end
Insert <E> before end
So... solutions:
Solution A is add the option to insert either before or after another
order... Solves this problem, doesn't solve:
Insert <D> after <B>
Insert <E> before <C>
Insert <F> in between D & E
Solution B is that clients add version# using:
<clientID><unique ID>
Where <ClientID> is player ID. Is there a protocol defined limit in
some way? If it is 255, it works out nicely... Otherwise 16bit is a
little too small.
Otherwise I need another version to fix that one, however it's not a
killer yet ;-)
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
