Re: [g-a-devel] FocuCaretTracker issues



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]