[webkit-dev] DOM tree surgery and DOM tree destruction
achats at avvanta.com
Wed Jun 25 14:17:58 PDT 2008
Obviously we're not out to violate the WebKit DOM API and memory management
model. We're having trouble mastering their unique features, and don't want
to get bogged down. My most recent email makes it clear that we'd like our
code to conform to the API, but don't know how to do it, or at least we're
not sure we know how to do it. Responses to the questions on the toy example
in the email would be a big help.
As far as manual destruction goes, we're facing not only the WebKit DOM API
and memory management model, but also the architecture of a browser session.
We're not letting WebKit's default treatment of Web pages proceed to its
natural conclusion, because that would involve a huge amount of processing
that's extraneous to our purposes. We'd really like to defer a careful
adaptation of the architecture. Until we get to this, knowing how to
manually destroy trees will be very useful.
Can you point to a document that supplements "RefPtr and PassRefPtr Basics,"
or is an update of that document?
----- Original Message -----
From: "Maciej Stachowiak" <mjs at apple.com>
To: "Pitaga" <achats at avvanta.com>
Cc: "Darin Adler" <darin at apple.com>; <webkit-dev at lists.webkit.org>
Sent: Wednesday, June 25, 2008 1:12 PM
Subject: Re: [webkit-dev] DOM tree surgery and DOM tree destruction
> On Jun 25, 2008, at 12:16 PM, Pitaga wrote:
>> Thanks very much for this response.
>> We (my co-workers and I) want to use WebKit modules selectively, without
>> running anything like full browser sessions. Over time, we'll do this as
>> cleanly as we can, taking full advantage of smart pointers. For now,
>> focused on implementing our own (non-trivial) algorithms. We're breaking
>> into browser sessions, running our algorithms on DOM trees, and worrying
>> little as possible about API issues. We're more than willing to write
>> to destroy objects. We're coping with smart pointers, rather than taking
>> advantage of them. If this seems like the wrong attitude, please excuse
>> on the grounds that it's appropriate for us to focus first on algorithm
>> Given that we're interfering with the mechanisms for automatic
>> and need to write code to destroy trees, how do we do this?
> If you want to use WebKit DOM classes in a way that violates their API
> and memory management model, I think you are on your own as to figuring
> out how to make it work.
More information about the webkit-dev