Nick Jenkins wrote:
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:
- A status update when someone starts editing something, or a periodic update as they make changes.
- A method for querying what the current status is of ongoing edits it.
- 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