But to get us
started, someone needs to make
that UI mockup.
Very draft mock-up of a possible UI, from what I think you're describing:
http://files.nickj.org/MediaWiki/ui-draft-mockup.png
In the picture, the "Notify others of my edit" box should be ticked (since it
is shown in the list).
Maybe "Notify others of my edit" should labelled "Notify others of my
progress"?
Maybe the number of characters changed should be shown, maybe it shouldn't.
Maybe the name of the other user should be shown, and maybe it shouldn't.
Maybe the user's own changes should be shown in the list, maybe they shouldn't.
Thanks for that. Can we have the HTML source for it?
For the messages between client JavaScript and the PHP
on the server, sounds like maybe there are 3 types of messages:
1) A status update when someone starts editing something, or a periodic update as they
make changes.
2) A method for querying what the current status is of ongoing edits it.
3) A response from the server as to what the status of current edits is.
Format 1 probably needs the summary, section, revision, time since the user last changed
anything in the textbox, and possibly the
number of characters changed. The server presumably already knows the username from the
cookie.
E.g.: (Section, chars modified, revision, seconds since last change, edit summary):
["Background",235,20060823110052,34,"Typo fixes"]
Format 2:
Can just be a get request, using the exact same URL format as per index.php :
e.g. GET
http://en.wikipedia.org/wiki/edit-status.php?title=User:Nickj/Sandbox
Possible response format from PHP on server for number 3 (in response to GET request #2)
is:
# No conflicts:
[]
# Only one conflict. Fields are: Username, section name, changed characters, timestamp of
version editing, seconds since last
change, edit summary:
[["User:Nickj","Background",235,20060823110052,34,"Typo
fixes"]]
# Two conflicts (sorted by seconds since last change?) :
[["User:Nickj","Background",235,20060823110052,34,"Typo
fixes"],["User:203.15.35.81","",1000,20041112231221,100,"I
am a Vandal!"]]
You probably also need a timeout mechanism (e.g. if haven't received a status report
from a client in 5 mins, then drop the user
from the list), and maybe also a message to inform the server if the user aborts the edit
(although they can just click the "back"
button, rather than clicking "cancel", in which case you probably won't get
the message).
I imagine we would have both a client-side timeout and a server-side
timeout. The client-side timeout would be a maximum idle period, it would
turn off the periodic updates to prevent excessive resource usage when the
user leaves the computer with an edit window open. The server-side timeout
would cancel the editing status when the client stops sending messages for
whatever reason. The server could also redundantly enforce the maximum idle
time. As for cancel buttons: is it possible to send a cancel message
asynchronously, without blocking the client from leaving the page?
-- Tim Starling