Re: [g-a-devel] FocuCaretTracker issues
- From: Joseph Scheuhammer <clown alum mit edu>
- To: gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel] FocuCaretTracker issues
- Date: Tue, 16 Jul 2013 16:32:46 -0400
Hi Alejandro,
Thanks for your input.
In any case, another pov for the same question would be: is there any
advantage on each client having their own instance of the tracker?
Because if there isn't any advantage, having this as a singleton have
the memory advantage of maintaining just one reference. Probably that is
a small advantage, but if having one instance per client have zero
advantages, the singleton option is still winning 1-0.
The main advantage of each client having their own copy of the tracker
is that there is no need to worry about accidentally deregistering the
events with atspi. With the singleton approach, the tracker has to note
the number of clients connected to it, and (perhaps) deregister when no
more clients are connected. Put concretely, when a client is no longer
interested in the tracker's signals, the client calls the tracker's
disconnect() method. When there are no more connections, then the
tracker can safely dereigster with atspi.
On the non-singleton design, the tracker does not have to manage this
since there is only one client connected to it. The logic is somewhat
simpler. When the client is done, the deregistration for that client's
instance of the tracker can be automatic. I'm actually leaning towards
this approach now, since the complexity associated with the singleton
design may be an example of the anti-pattern you noted, "Accidental
complexity".
On the other hand, with a singleton, the dbus traffic is limited to one
atspi registration (well, actually three, but that's a detail). With
mutliple trackers, there is one atspi registration per tracker. How
costly is that extra dbus traffic? (Probably a Mike question).
Still thinking about the rest. However:
In fact,
doing that is a example of a well known anti-pattern: "Accidental
complexity" [1]
[1]http://en.wikipedia.org/wiki/Accidental_complexity
Thanks for the link. :-)
--
;;;;joseph.
'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
- J. D. Klaun -
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]