(In reply to comment #44)
> Just a quick note, in case people are pushing hard on getting this done so it
> can be used for VisualEditor, it's not the direction we're looking at taking
> for VE.
> 
> * We would need something that is client-side, not server-side (this makes
> things faster and avoids the really icky legal issues).

Are these 'icky legal issues' explained somewhere? Are you referring to the need for explicit copyright signoff before *distribution*?  Why cant that be delayed until the real save button is pressed?

A client-side solution is not going to go down well.  People switch between computers and browsers, use internet cafes, etc.  Wikipedia and VE are a web-app; ordinary users will expect auto-save to persist across their user-agents.  A client side solution isnt auto-save; it is a data-recovery mechanism only, which is still useful in its own right, but each client will have its own quirks, etc.

> * We would need something that lets us persist VE linear-models, or at least
> Parsoid HTML+RDFa (otherwise each save will take dozens of seconds of
> computation, slowing clients down and adding to burdens on the cluster; until
> server-side storage of Parsoid HTML+RDFa is undertaken, there's nowhere
> really
> appropriate for this to be saved for the Drafts extension to implement, which
> is currently wikitext-based)

There is no client-side hit required to persist VE as wikitext.  VE already has an API call that accepts HTML+RDFa and produces wikitext; VE can add an API call that accepts HTML+RDFa and persists it as wikitext into the Drafts tables.

Not sure that there is going to be an overall additional burden to the servers either.  Converting HTML+RDFa to wikitext will be a memory&processor hit to the app servers, whereas persisting HTML+RDFa into the database is an IO hit as compared to wikitext.

Besides, what percentage of overall server load is spent on processing page saves to content pages (excluding rendering as autosave in VE doesnt need a render hit)?  I'm guessing that isn't where the WMF resources are being pinched.

> * We would want (but not strictly /need/) something very flexible, so we
> could
> persist undo stacks, etc. which could add a huge amount of complexity to the
> Drafts extension for just one use case/client.

I agree with Legoktm; it would be great if the source editor also had some features added to it.  undo stacks is a major part of the problems holding up the deployment of Drafts; Drafts needs to handle multiple revisions of the same page being saved as a draft.   I hear the majority of the editor base tend to use the source editor most of the time ;-)