"Bo Leuf" <[EMAIL PROTECTED]> wrote:
> Now, how would you track "consecutive saves from the same
> request"? Insert some wiki-generated unique identifier (date-time?)
> into the form data that gets returned by the client post? Hmm, what
> happens if the user backs up two edit requests, not one...? (Just
> pondering aloud....)
>
I would also point out that date+time does not make a unique timestamp,
either :). So make it an ever-increasing serial number. Happily,
Squeak is just fine using 32-bit numbers, so we don't even have to worry
about wrappover.
Now, I'm guessing that if someone backs up *two* edit requests ago, that
it would be okay for an edit conflict to still be issued. Heck,
arguably it *is* an edit conflict -- they may well have done this by
accident.
Overall, this general scheme seems to lick the case of one previous
edit, while still generating conflicts in all the other cases:
1. Every edit form sent out has two pieces of information in it: the
version number it was requested of, and a serial number which is unique
for the swiki. Call this later number an "edit identifier".
2. Whenever a save succeeds, the edit identifier is saved along with
the page. (Perhaps only in memory, though, so that this all works
across reboots).
3. Whenever a save is attempted, if the edit identifier is the same as
the edit identifier at the last save, then let the save succeed no
matter what the version numbers say.
4. Otherwise, whenever a save is attempted, let it succeed if and only
if the version number supplied is the same as the current version.
For simplicity, it's not even necessary to give the "conflicts page" an
edit identifier -- simply don't allow multiple saves from the conflicts
page. (Though certainly it would be *nice* to extend the scheme for
edit conflicts, as well).
-Lex
