...
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.

This is one of the main use cases that the 'Collection' interface was
designed for. Collection is an AT-SPI interface currently under
development, not sure what the calendar for it looks like at the moment.

The idea was to allow the application to perform the search logic rather
then either performing the search via IPC or pulling the whole DOM/tree
over and searching in the client.

This also helps with the "infinite space" problem, insofar as Collection
allows limiting the
number of responses (along with response ordering), and also allows
returning only the number of "hits", both of which can be used by an
intelligent client to avoid "infinity" traps.

This is IMHO the only sane way to do this anyway; eg. exposing infinite
spaces: eg. "all time", or "1 million x 16k spreadsheet cells" via the
current interface is somewhat tortured anyway.

Also, regarding a recent StateSet discussion, the interface was
conceived with the notion that clients would reuse StateSet objects,
i.e. that they would be somewhat persistent in the client (explicit
refcount again, I know). This would reduce the ref/unref pair to a
"once per logic combination" overhead.

StateSet was also designed to reduce load on the server - i.e. only the
pieces of state which are to be used must be created. Some bits of
state are cheap and easy for the server to determine, but perhaps not
all. Also the StateSet allows, if memory serves me correctly, for more
complex logic that just a bunch of booleans.
I'm sure I'll have more comments about the current discussion after the
holidays.

Best regards and Merry Christmas/Happy Holidays,
Bill

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.