Re: [g-a-devel] FocuCaretTracker issues

[Piñeiro <apinheiro igalia com>]

On 07/16/2013 10:32 PM, Joseph Scheuhammer wrote:
> 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".

Ok, in that sense it is true that the non-singleton option have
advantages. As far as I see, with the information we have right now, the
non-singleton option is the most sensible (and simpler one). I agree
that the most sensible is the non-singleton option. If in the future we
found a decisive reason to use a singleton, we can change that if needed.
> 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).

FWIW, when we talk about problems with DBUS traffic is related with a
big amount of events (flood of events) and not about some. For example,
in the past it was a problem when a user with a really big amount of
music on a USB connected it, and the music player started to add each
song to his list, as suddenly the IPC started to flood the computer with
"children-changed" signals. AFAIU, we are not going to have hundred or
thousands of trackers, so having two or three registration events
shouldn't be a problem. As I said the problem is when you have like 100
dbus events per second, for example.

> Still thinking about the rest.  However:

Ok.

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

No problem. I'm a expert on anti-patterns, I committed most of them ;)
Here you have a full list:
http://en.wikipedia.org/wiki/Anti-pattern#Software_engineering

BR

-- 
Alejandro Piñeiro Iglesias