[RFC] Autosave

[lothario]

Motivation
When you are writing long replies to forum topics, there is nothing worse than experiencing an error on submission, leaving no (obvious) way of retrieving it again. Solutions to this, for me, have been copying the text to Notepad (or just the clipboard), before submitting. This is not a good solution in my opinion.

Proposal
Create an autosave feature, that after a set time saves the currently entered data into a temporary database, which is then deleted on succesful submission. If the submission goes bad, the user is prompted with an option to restore the autosaved data.

The autosave feature would probably only work for users with javascript enabled.

[Nelsaidi]

It would put an immense load on the database and the server, it is better suited as a mod for boards who need it and have the computing power to serve it.

[lothario]

It would put an immense load on the database and the server, it is better suited as a mod for boards who need it and have the computing power to serve it.

What's the difference between the server saving the post and the user pressing submit and saving the post? It wouldn't be any different really. If it's done every 5 minutes I can't see why it would be a load.

[Sierron]

If 10 users post some content and writing some big text, you don't have 10 saves to database, but 20 for 10 mins.

30 users + 10 minutes = 60 saves to database
50 users + 10 minutes = 100 saves to database

The database will be written more frequently. While perhaps some small post are made at the same time.

[lothario]

If 10 users post some content and writing some big text, you don't have 10 saves to database, but 20 for 10 mins.

30 users + 10 minutes = 60 saves to database
50 users + 10 minutes = 100 saves to database

The database will be written more frequently. While perhaps some small post are made at the same time.

What about a client solution then, save it as a cookie or a session file?

[igorw]

I was about to say, something like this should probably be client-side. There are a few new "HTML5" client side persistence APIs that could be used for this (please don't bloat the poor cookies). But any decent browser supports the back button.

[DrStrangelove]

caching a post client side sounds like the way to go but do you have any sources on that?
were you thinking of something like javascript+flat file?

i know firefox etc. stores post data, but I wouldn't call it reliable, on the contrary.

[DavidIQ]

It could still be a round-trip to the database I think through an AJAX call. Wouldn't be any more heavy on the database than actually posting I think. The AutoSave would only be triggered after a certain amount of text has been changed as well as some specified amount of time has passed. This could turn fairly complex though when it comes time to retrieve the actual post(s). But for that maybe a list of auto-saved posts would suffice. Then the question becomes how long do you want to store these automatically saved "ghost" posts? This could get fairly complex in a heartbeat...

[DrStrangelove]

does it have to be proper? autosave is a last-resort feature to save the contents of a long post for a short amount of time, there's no need to involve server side at all IMO, and that keeps things simple as they ought to be.

if javascript stores the post in a local file named with session id, topic id and post id, it should be rather quick to do a check to see if there's autosaved content for the post in question. if there is, then a small dialogue can be inserted with js+dom. if the post disappeared altogether... perhaps a check+dialogue should be done in the topic screen?

recommend scrambling the locally stored posts btw.

it should work in theory. am i missing something here?

[Nelsaidi]

I remember a post about using local storage - RFC somewhere, had some good points about autosaving, how it would work, downsides, etc etc.

An outcome of that I remember was that if the post didnt submit due to server error, chances are it wouldnt have saved a draft either.

My reasoning for saying database load would increase alot is because with the same actvitiy/forum users/posts, you are adding alot to it. Lets say everyone who types a post for more than two minutes (quality not qunatity, so tbh X characters isnt better than a time frame) - their post gets saved, and likewise until they submit. Then posts are deleted, ghost drafts are stored in the database, purged, etc, etc - The way I see it is that it isnt really ideal for shared hosting.

HTML5's Local Storage on the other hand is fast, drafts and multiple drafts of a post can be stored indefinitely and there's no server side constraints and is supported by the latest versions of all major browsers (http://www.findmebyip.com/litmus/) , with regards to unsupported yet widely used ie6 - http://support.microsoft.com/gp/lifesupsps , could potentially be unsupported by microsoft come 3.2, but imo you cant compromise based on what IE6 does and does not support, especially since this only enhances user experience and in no way prevents the user from using the board.