phpwiki-talk

[Phpwiki-talk] Diff feature request...

[Seth C. <se...@eu...>]

So long as we are talking about diffs....

consider this a feature request.
I've noticed that the page-edit lock frustrates users, when they do a long
edit and it fails.
It would be very very nice to have a diff feature there....
Maybe even a merge?
Merging older versions (admin only?) would also be great, as I've noticed
that some people will (due to the above frustration) cut the whole thing,
paste into a new edit window, and blammo, lose of the other edits (it's in
history, but has been effectively lost, until someone rescues it).

P.S. I got the PHPWiki module for PHPNuke.  The author wants me to try it
out, and then if it works, he'll put someone public... but if anyone of you
on the list want to try it (the more testers the better), let me know.

Re: [Phpwiki-talk] Diff feature request...

[Adam S. <ad...@pe...>]

> I've noticed that the page-edit lock frustrates users, when they do a
> long edit and it fails.

i've never understood this.  why don't wiki's tell you when you *try* to
edit a page that someone else is already editing it?  that seems more
sensible to me then after a page has been being edited for X amount of
time user should have the option of waiting or breaking the lock.

adam.

Re: [Phpwiki-talk] Diff feature request...

[Steve W. <sw...@pa...>]

On Tue, 18 Sep 2001, Adam Shand wrote:

>
> > I've noticed that the page-edit lock frustrates users, when they do a
> > long edit and it fails.
>
> i've never understood this.  why don't wiki's tell you when you *try* to
> edit a page that someone else is already editing it?  that seems more
> sensible to me then after a page has been being edited for X amount of
> time user should have the option of waiting or breaking the lock.

HTTP is a stateless protocol. That is, you make a connection, get the
page, and disconnect. Compare this to a telnet session, which is stateful.

If Keesha fetches HomePage and starts to edit it, she gets the current
version in the Edit page. Maybe she edits it, maybe not. Maybe she goes
home for the day.

Elmer then wants to edit HomePage. But the Wiki tells him someone else is
editing it so he waits, and waits and waits.

Meanwhile Keesha's computer is crashed overnight by the new "nimbda" worm.
She never gets to save her changes. In fact, now there is a lock on the
file and noone can change it.

This is one of many scenarios possible because HTTP is stateless. The
server has no way of knowing when (if ever) Keesha will save her changes.

WebDAV extends the HTTP with new features to handle collaboration like
this. A WikiWikiWeb, however, is just a quick and dirty solution to
collaboration on content. We don't worry (much) about such fundamental
problems.

If you think the current situation is frustrating, the previous situation
was far far worse: you'd spend a long time making changes to a page, save
those changes, and then come back an hour later and find someone
accidentally saved *their* copy over yours, and all your changes are not
only lost, they are irrecoverable! This is the Lost Update Problem.

Now, at least you can pull your copy from the archive. The irritating
page-edit lock, as it exists now, at least prevents you from losing
everything.

~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Diff feature request...

[Reini U. <ru...@x-...>]

Steve Wainstead schrieb:
> On Tue, 18 Sep 2001, Adam Shand wrote:
> > > I've noticed that the page-edit lock frustrates users, when they do a
> > > long edit and it fails.
> >
> > i've never understood this.  why don't wiki's tell you when you *try* to
> > edit a page that someone else is already editing it?  that seems more
> > sensible to me then after a page has been being edited for X amount of
> > time user should have the option of waiting or breaking the lock.
> 
> HTTP is a stateless protocol. That is, you make a connection, get the
> page, and disconnect. Compare this to a telnet session, which is stateful.

if we use php4 and sessions or the session support from the phplib we can 
add state. 

I do support something like "who's online" and "who's looking at that".
timeout is usually 30 minutes.
every hit has to update the session state (either memory, file or database), 
propagating the session id via url params or cookies. 
and every hit has to purge old sessions. no big deal. 
this way I propagate the user_name and more without cookies.

anyway, just to solve the problem to know if someone else is editing 
the same page, adding session support for phpwiki is probably overkill.

we could get rid of cookies. cookies could be made optional. 
if none are supported, the session is transported via url or hidden inputs 
in post forms.

> If you think the current situation is frustrating, the previous situation
> was far far worse: you'd spend a long time making changes to a page, save
> those changes, and then come back an hour later and find someone
> accidentally saved *their* copy over yours, and all your changes are not
> only lost, they are irrecoverable! This is the Lost Update Problem.
> 
> Now, at least you can pull your copy from the archive. The irritating
> page-edit lock, as it exists now, at least prevents you from losing
> everything.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Diff feature request...

[Adam S. <ad...@pe...>]

> I do support something like "who's online" and "who's looking at
> that". timeout is usually 30 minutes. every hit has to update the
> session state (either memory, file or database), propagating the
> session id via url params or cookies.  and every hit has to purge old
> sessions. no big deal.  this way I propagate the user_name and more
> without cookies.

that would actually be kind of a cool feature.  in comparison to what the
wiki already has to do to serve a page how noticeable is the overhead from
using sessions?

if it's minimal what is the downside to using sessions?

adam.

Re: [Phpwiki-talk] Diff feature request...

[Jeff D. <da...@da...>]

On Sep 18, 2001, Adam Shand said:
> 
> that would actually be kind of a cool feature.  in comparison to what the
> wiki already has to do to serve a page how noticeable is the overhead from
> using sessions?
> 
> if it's minimal what is the downside to using sessions?
> 

I just thought I'd add:

Sessions are already being used in the latest hacks.  At this point
as a kluge to get around funnyness in the current user login code,
all of which is going to be replaced sometime fairly soon, I hope.
(Mozilla won't accept cookies as part of a "401 unauthorized"
response.)