mjs at apple.com
Fri Jul 24 23:52:28 PDT 2009
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
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
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.
> 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 at lists.webkit.org
More information about the webkit-dev