- without significant/onerous change to any existing code that uses moodle forms (i.e. if you just have to add $form->enable_autosave() that's okay, but if you have to write whole php scripts, ugh).
This is certainly an important point. Currently my soultion requires each form to have it's own Javascript function and PHP method to handle getting the data from the field, and actually writing to the database, respectively.
Using moodle forms would help with this as each field type could have javascript written to handle it as needed, and pass a key-value pair of the field to be updated along with a record ID to an AJAX request. This could then pass to a core PHP script which passes it on to an autosave function for the plugin/module. I can't really imagine it being possible with just an ->enable_autosave() unless we prescibe form and database field naming conventions, but a fairly simple PHP function in each plugin's library (perhaps a method of the form's class?) sounds feasible for a lot of cases.
- without breaking anything
As long as progressive enhancement principles are followed, I can see no reason why adding autosaving should break existing functionality. Obviously there are many who know the Moodle core a lot better than I, who may know of heffalump traps that I haven't thought about.
- without causing performance problems (do you want to have a manual save button as well/instead of autosave?)
That's another important one to watch out for - autosaving when each field on a form changes does generate lots of HTTP requests (albeit very small ones) which add to the server load. I've certainly found this noticeable in a situation where lots of people are using the form at once, although in an everyday situation it's not caused problems.
As for manual saving as well, I've taken the approach that the manual save button is disabled (or replaced with appropriate navigation), then enabled again if autosaving fails for any reason.
- with an okay user interface (how do you get back to the lost content? what if drafts were saved but you don't want that post, how do you delete? etc)
My inital thoughts are that UI for handling drafts should be kept to a minimum - if a user has saved a draft then subsequently left and returned to a page, the draft they saved should be pre-filled in the form. The draft could expire after a time, if unused. Beyond perhaps a "clear form" or "revert to saved" button when an unwanted draft is loaded, the only need I could see for extra UI is if multiple drafts/versions are saved, which might be an over-complication.
