On Jul 24, 2009, at 2:18 PM, Darin Adler wrote:
On Jul 24, 2009, at 11:05 AM, Adam Barth wrote:
Do you have specific areas you're concerned about that we can be on
the lookout for?
I tried to think this through, but only had a few minutes free:
A minor concern is that Frame has a constellation of helper classes
to help keep it simple, including ScriptController, but Document
does not, so this change will add more non-“model” things to the
Document header, muddying our architecture.
I think that long-term we need to have a class to represent all the
state of a Frame that changes whenever the document changes. Right now
the closest we have to that is DocumentLoader, but it doesn't really
hold all of the per-document state, some needs to be swapped out
separately.
I could imagine three plausible designs:
1) Document becomes the master class that owns everything which needs
to change when the document changes, including the inner window and
the DocumentLoader.
2) DocumentLoader becomes the master class that owns everything, and
the relevant fields are moved from other classes, such as Frame, to
DocumentLoader. Document gets a backpointer to DocumentLoader but
otherwise can be mostly limited to its primary role of implementing
the DOM document.
3) A new class becomes the master class and owns all three of
DocumentLoader, Document and the inner window.
I personally like #2 or #3 better than #1, I think Document itself
will be easier to understand if it remains primarily an implementation
of the DOM Document interface. I think #2 is plausible and maybe a
good idea, since a lot of the trickiness of when to swap documents
relates to loading.
I think that even though this is the right long-term architectural
direction, we should be very careful and do changes towards this
design in steps. The reason is that it ties into document transition
and central object lifetime, which are both areas that are somewhat
fragile to compatibility, robustness and security bugs.
So probably I wouldn't make too much of this redesign a prerequisite
for other changes.
Regards,
Maciej
There are dormant documents that are in the back/forward cache, and
it’s important that we not do more work in these. At the moment,
it’s possible that the fact that frame() is 0 is how certain
operations are disabled in such things.
The same type of issue could apply to documents that are not in the
back/forward cache, and no longer in the frame, but still alive for
some reason.
Creation and teardown seem like the trickiest areas. The timing of
creation of the global object vs. the document might end up being
different than today.
The timing issues are likely to be different per-platform because of
the excessive complexity of the FrameLoaderClient, so we would want
to make the changes in small steps with a lot of testing.
-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
