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 _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
