I feel compelled to clarify my views:

Order of events:

• Editor-A is browsing lists of nodes to edit
• Editor-A sees a post that requires <code> tags
• Editor-A selects the 'Lock node for editing' checkbox (only seen by editors)
• Page is refreshed into browser, with a 5 (or 10, or 15) minute lock timer set
• Editor-B notes node needs <code> tags also.
• Editor-B selects the 'Lock node for editing' checkbox
• Editor-B gets a display saying 'Node Locked for Editing by Editor-A'
• Editor-B sighs, hopes Editor-A doesn't make a big hairy mess of it, and moves on
• Editor-A realizes he can't type <code> in 5 minutes, submits node back to system
• Lock bit remains set, timer recycled to 5 minutes
• Editor-A finally gets his act together, submits node again
• Editor-A may now
  • Clear the lock request checkbox, immediately releasing the node; or,
  • Wander off into the weeds, and 5 minutes later the system will clear the lock
• System appends a message to [Edit History] indicating Editor-A made changes at 2001/02/21 00:02:22
• Everyone heads off to Skiles, and has a brew

Perhaps I'm over-simplifying it, but this seems to be the easiest recourse, with the least user impact, and guarantees that 2 users never edit the node at the same time. Unless, of course, I've missed something...

Oh, sure, just make it sound simple. (: This seems like a fine solution. I still slightly prefer mine but for no really compelling reasons (they mostly boil down to personal taste). I'll summarize them, just FYI (where "Y" stand for "y'all's" in this case).

I think my method will also be useful for giving feed back to non-editors replying to nodes.

I find picking the right time-out (5 minutes) to often be a continuing source of change requests. There are inevitably going to be cases where it seems too long or too short. My scheme mostly lets the humans evaluate the situation to determine a good time-out value (and I'd prefer that hitting "Preview" updates the time that is displayed to the next editor(s)). Adam has already noted that he disagrees with me on that. I have a time-out value, but it isn't a critical one and can be made very long with little problem (you just get notified that jcwren might still be editting a node even though it has been an entire hour since he started). But, like I said, personal taste.

I find optimistic locking often much easier to implement correctly (when you get down to the little details) because the locking and unlocking happen very close together and so can be done in the same subroutine, for example.

        - tye (but my friends call me "Tye")

I like this. Especially the Skiles part. :-)

So, would "Edit History" show the fact that Editor A never actually submitted an edit? Or would Editor A just not show up in that case? Also, I already mentioned this, but it bears repeating, do the editors get a preview before submitting?

Oh yes, and I don't think 5 or 10 minutes is long enough. Network connections can be slow, editors can get distracted by co-workers, etc. I think 20 minutes is a better timeout.

Editor-B is the person who never actually submitted it, and the [Edit History] wouldn't need to reflect that he even tried. It could, for collision statistics (!), but it wouldn't be required.

5 minutes is, of course, arbitrary. It's plenty to change a simple spelling, worse if you're doing heavy duty reformatting. I'm not really fond of this idea, but one could add a box that would allow you to enter the expected number of minutes you think it might take you to edit it. But that's yucky.

Of course, none of these nodes are critical to national security, so if someone does start an edit, and the system timer is 30 minutes, it just means that it'll be about 30 minutes until the next person can edit it. I don't see that as a major issue.

And as far as /msg'ing the original author that his node has been edited, I don't know how I feel about that. I imagine it would be easy enough for vroom to add that, but I don't know if it's necessary. Perhaps YACB (Yet Another Check Box) to make that an option. If someone is fixing code tags, I don't see where the author needs to know about it, since s/he probably wasn't smart enough in the first place. On the other hand, if you're deleting socially questionable comments, the author has more of a right to know. I'm indifferent, at least until I see how it goes.

I'm sort of the mind that the [Edit History] should be public, so that non-editors can make a sport of checking out nodes that have been edited, and then start a whole list of threads to be edited by complaining about the ones that have been edited...

--Chris

e-mail jcwren

I think that a simple solution is a good starting point, and if we find that a more "complex" solution is needed, it can always be changed. "Simple" in my book is that an editor selects to edit a node, and if no one else is editing it, is given the editor screen. Otherwise the editor is given the name of the current editor. A lock expires after 20 or 30 minutes.

If you want to prevent two editors from editing the same node simultaneously, then you'll need some form of "pessimistic" locking scheme. Obtain some form of lock up front, preventing anyone else from even attempting an edit.

Alternatively, if you judge that the chance of edit collisions is slim, you can adopt a less expensive "optimistic" scheme were the first edit saved wins. A hidden timestamp in the edit form is sufficient for this. If the timestamp doesn't match the page/node timestamp when a save is attempted, the save loses (becomes a merge attempt).

A data point:

I use an optimistic scheme in a Wiki clone. It gets far less traffic than Perlmonks, but it's often the case that there's a "working set" of a dozen active pages during the course of a day, and edit collisions are rare. Given how quickly people jump on new nodes here, that might not be the case here.

As a further clarification, I am still unconvinced that there is a problem with multiple editors editing at once. If a node requires editing, it is probably obvious what the edit is. Should 2 people race to do the same work, oh well.

At most have a message saying that "so and so started editing this time X ago" and let the editor decide whether they want to proceed.

I agree. But since vroom asked, I assumed that he had a reason (such as wanting to implement automatic "undo").

If you add to the above scheme a simple atomic test at final commit time to see whether the node has be changed since the editting began (as discussed already), then the editor can be warned that they are about to overwrite someone else's work. At that point, they can open another window and view the other work and decide whether to commit their own changes or not (or to merge some of the other editor's changes, etc.).

        - tye (but my friends call me "Tye")

Would that message clear when the "other" editor stubmit's the edit? Also, 'x' becomes a variable timeout, right?