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

[Rob Taylor <rob taylor codethink co uk>]

Michael Meeks wrote:
> 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.

Yep, lets do this! When would be good for you? anytime's fine for us.

Thanks,
Rob

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


-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk