Re: [Accessibility] a11y / D-Bus / lifecycle ...

Hi Rob,

	First - it'd be great to have a quick call with you guys at some stage
just to chew this over & get on the same page.

On Tue, 2007-12-18 at 14:11 +0000, Rob Taylor wrote:
> > 	Weell ... ;-) yes, if you can fuse the IPC layer and the lifecycle
> > layer (as could not be done in CORBA) this is somewhat possible, though
> > when you have 3 parties involved it's going to get difficult:
> > transfering object ownership from a->b->c is quite exciting, albeit
> > somewhat uncommon: unless you're going to have a separate event broker
> > like at-spi-registryd - which is prolly what you want to do filtering,
> > registration etc.
> 
> Well, 'fuse' is a pretty strong term, 'predicated on' would be more
> correct. Its simply possible because there's a bus that tells you when
> connections go away, and you always know what connection a message comes
> from.

	Sure, but if you have direct connections to applications, and also
indirect ones (eg. via the bus) then you end up with interesting
problems of transfering / cross-associating references: and this is with
a simple toplogy - in the general case with Bonobo: of components
passing references between themselves frequently it's just
nightmarish :-). IHMO mandating a given topology is the first step in
making the problem tractable. Then being able to do (eg.) per-connection
lifecycle tracking is necessary - also enforcing a consistent reference
counting & transferal policy etc. etc. you have to fuse lifecycle with
the IPC to have any chance of getting this right [ at least that's what
we learned in bonobo ]. ie. "signal comes in => we now own 1 more ref on
Foo" [ necessary to avoid leaks when the weak/client representation of
Foo goes away ]

> Why would you need to have an ownership scheme? surely just plain old
> refcounting is sufficient? Though that raises an interesting point, you
> couldn't have floating refs for object references in signal emissions,

	Quite ;-) is someone listening to unref it ? does each recipient unref
it ? does that mean we need to know (semi-accurately) how many listeners
there will be (etc. etc. ;-) - as I mentioned explicit lifecycle is a
horrific problem space ;->

> > 	Are you bearing in mind that all the reference counting pain is to
> > satisfy a situation that doesn't need to exist & should never have been
> > postulated ? :-) [ exposing an entire DOM ].
> 
> Indeed I am, but I haven't had a brainwave on a better solution. Got any
> ideas?

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

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

-- 
 [email protected]  <><, Pseudo Engineer, itinerant idiot