101001 - Editor saving APIs suck rocks

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Akkana Peck]

There are lots of different ways to save.  The editor has OutputToString and
OutputToString, but it actually doesn't use either one when it saves; instead it
calls an interface in nsIDiskDocument, which lives somewhere else entirely even
though (I think) it's editor-specific code which is not used by anyone except
editor.  (When the browser saves it does something else again -- fetches from
netlib and saves that without looking at the dom.)  Then there's
nsIDocumentEncoder, which was meant to be a generic interface but I don't think
the nsIDiskDocument stuff is using it.  Mail/News code supposedly depended on
the editor's OutputToStream code (which was the only client for that interface)
but Kathy says no one's using it any more (so what is mail/news using now?)

We need a consistent interface that everyone can call.  We should do this in
time for publishing, before we have to write more bad code dependant on the
inconsistent interfaces.

I suspect that we should use nsIDocumentEncoder and have wrappers inside editor,
unless someone makes a case that someone outside editor needs something that's
in nsIDiskDocument that nsIDocumentEncoder doesn't provide.

Comment 1

[Akkana Peck]

Targeting sooner than moz 1.0, so we can have it in place before the bulk of
publishing needs to be written.

Comment 2

[Simon Fraser [no longer active]]

Note that there are a number of different saving scenarios, so I don't think it 
can be a case of 'one output routine fits all'. Saving scenarios:

1. Saving from the browser. In this case, we need to save exactly what the
   web server served up, so getting it from necko/the cache is the right thing
   to do. However, there does need to be a way to save as text (this might use
   the following).

2. Saving from editor (editor save, mail etc). This needs to do DOM->html or text
   conversion.

nsIDiskDocument's main role is to associate a file on disk (or perhaps on a 
remote server) with an in-memory nsDocument. A part of that role is manageing 
document dirty status. It does not necessarily have to deal with document output.

Comment 3

[Akkana Peck]

I should clarify: I'm only suggesting a mechanism for the dom-to-output case,
not for the netlib-to-output (browser can handle that as they see fit).

Editor handles dirty bit management, doesn't it?  Does anyone else besides
editor need that?

With publishing, the association between dom and "disk" becomes more complicated
(since it may be an association between a dom tree and some remote publishing
site somewhere).

Comment 4

[Akkana Peck]

We've looked at this a bit but it's not going to be solved in time for 0.9.7. 
Pushing off.

Comment 5

[Akkana Peck]

We're making some progress, but aren't going to be ready for 0.9.7 -- changing
TM to track depandant bugs.

Comment 6

[Akkana Peck]

Work continues ... but won't be finished for this milestone.

Comment 7

[Akkana Peck]

Really, the biggest issue here was getting the nsIDiskDocument out of the tree,
and switching to use nsIWebBrowserPersist.  The dependencies here weren't well
done (the first one was apparently a wrong number, and the second is Futured for
freezing the API).  But Kathy just removed nsIDiskDocument, and saving no longer
sucks rocks, and therefore I'm closing this bug. :-)

Comment 8

[sujay]

Akkana please verify and mark verified-fixed...thanks!

Comment 9

[sujay]

Akkana please verify and mark verified-fixed...thanks!

Comment 10

[Kathleen :Brade]

v