...
Sure: it's mostly a matter of socialisation:
* first we ask the ATs what they actually use "the whole DOM"
for:
+ eg. "count number of headings in a document"
+ "skip to next heading quickly"
* Then we create a new 'Browse' interface that can be used for
these things:
+ this interface would broadly behave like a set of
keybindings: skip to next heading eg. which would
substantially alter the view / invalidate a load of
previously 'live' peers - but get what you want.
+ Other ideas might be a separate 'View' concept that
would be an 'off-screen' view of headings eg.
Actually I'm not really convinced that exposing the DOM necessarily
implies reference counting, we still have the base lifecycle management
of the 'page' being 'visible' surely ?
Nah; that's the problem - exposing the DOM means exposing the whole
document model, including tons of things that are off-screen. ie. it's
easy to say "give me all headings" - ~none of which are visible, or to
iterate over the entire document - a paragraph at a time, unreffing them
- most of which are not visible. [ you see the issue I hope ].
Its simply a matter of how
efficient exposing the dom is, and a dbus-basing interface would imply
that we don't need real objects representing the members of the DOM,
gecko could just talk dbus directly. (Obviously this is more work than
just being able to plug into the current ATK stuff though)
Yep, that busts ATK and it's semantics quite badly. Currently eg. you
get object lifecycle warnings (AFAIR) mostly only for live peers: ie. we
don't go creating them to tell people we're freeing them ;-)
The way OO.o does this (FWIW) is to only maintain peers for visible (or
nearly-visible) pieces of the document - if you play with a recent
version it uses ATK natively: I'd like to move all apps to doing that -
to remove these problems, though of course we need to expose whatever
the ATs want & need to make this work nicely.
HTH,
Michael.