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
> >
