Lex, quite true. As you say IP=user stands a greater chance of
breaking when proxies are in the loop. Thanks for a timely reminder
to note the many-users-same-IP issue in the wiki book where I
mention the this. It's true for dial-ups as well, where x number of
IPs are assigned dynamically as users connect, so it is possible that
two users on the same ISP who happen to edit the same page could
end up with the same IP within 10 minutes of each other. Unlikely of
course, but according to Murphy, it will happen, sometime.
Clearly, one needs to know what kind of access will be relevant if
setting something like that up.
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....)
Seriously, thanks for the response. I'll post a heads-up here when
the book is in production. (The Wiki Way, Bo Leuf & Ward
Cunningham, Addison Wesley ISBN: 020171499X -- I expect printing
to commence earliest Nov-Dec the way it looks now, but it could be
later -- don't know how long the post-submission processing will take.
I expect that to start before end of month though.)
/ Bo
Lex Spoon, on 12 Oct 2000, at 11:40, you wrote:
> Using IP=user is tempting, because it is often accurate.
>
> However, it is also often inaccurate. One example would be caching
> proxies, which are becoming more and more common. Another example,
> consider people running text-mode browsers off of a shared server like
> Tech's acme. Despite the stuff Microsoft and Apple push, multiuser
> computers have existed for well over 30 years.
>
>
> Overall, the general approach of "if it's the same user, it's okay",
> is fine, except that it's hard to track users accurately. Using IP
> will work for particular installations, but then suddenly it will fail
> for others and people will start quietly losing edits again. A safer
> approach but still good-enough approach would seem to be to watch
> which edit request a save came from. Consecutive saves from the same
> request should be acceptible.
>
>
> -Lex
>
>
>
>
> "Bo Leuf" <[EMAIL PROTECTED]> wrote:
> > I've (in ordinary wiki) tried this variation to avoid spurious
> > conflicts, tracking a page version number.
> >
> > IF edit post has same version as current version, everything is
> > fine. Save and bump up version.
> >
> > IF edit post version is less than current wiki version AND
> > posting is from same IP as current version AND this is within
> > (arbitrary but reasonable) interval, assume this is a repost
> > from same user from cached form. Allow save as before.
> >
> > ELSE flag as version conflict and ask user to reconcile any
> > differences.
> >
> > On personal wiki I use 10 minutes as interval, and also hold off RCS
> > processing for reposts by same user, figuring it's often minor
> > corrections I've made to a previous change.
> >
> > Seems to work.
> >
> > / Bo
> >
> >
> > Lex Spoon, on 11 Oct 2000, at 18:45, you wrote:
> >
> > > "Jochen F. Rick" <[EMAIL PROTECTED]> wrote:
> > > > recently somebody showed me a problem with Swiki that seems to
> > > > be MSIE only. It was shown to me on a Mac running MSIE4.5. Here
> > > > is how it shows up.
> > > >
> > > > 1. edit a page
> > > > 2. save that page
> > > > 3. hit the back button to go back to that page
> > > > 4. change some more stuff
> > > > 5. save again
> > > > 6. you get an edit conflict though there shouldn't be one
> > > >
> > > > I cannot replicate this on Netscape. When the edit page comes
> > > > up, I try to inform the browser through HTTP that this should
> > > > not be cached, but apparently MSIE does not listen. What can be
> > > > done?
> > > >
> > >
> > > Welllll, arguably hitting "back" should take you back to the
> > > version you actually looked at, not the most recent version of the
> > > page you looked at. So Microsoft isn't really doing something
> > > crazy here. If this argument bothers you, you might try writing a
> > > letter to Microsoft about it. But what to do in the mean time?
> > >
> > > Alternative 1: make the edit-conflict page clearer. I've never
> > > read through the whole thing, to be honest. But in this
> > > particular case, people should be able to figure out that they can
> > > just hit "save" and it will be okay.
> > >
> > > Alternative 2: make this particular case not an edit conflict.
> > > One way would be to send out a unique "edit instance" serial
> > > number whenever someone hits an edit link. Then, the new rule for
> > > an edit conflict would be "someone has tried to save after
> > > editting an old version of the page, *unless* they are saving from
> > > the same edit instance that did the last save, and the last save
> > > did not have a conflict". Something like that. It's a pain, but
> > > it should be both safe and very user friendly.
> > >
> > >
> > > -Lex
> > >
>
--
Bo Leuf
The Leuf Project
LeufOrg -- http://www.leuf.org/
