On Tue, Jun 1, 2010 at 3:47 PM, Dario Freddi <drf54...@gmail.com> wrote: > Hi, > > On Monday 31 May 2010 20:39:21 Olli Salli wrote: >> >> If this contact building in a FIFO queue stuff seems a bit too much, >> feel free to just skip it but in that case remove / comment out ALL of >> the connection tracking - there's not much use for signals which might >> contain the contact (the useful bit) or NULL arbitrarily. > > The idea is to implement what you said above and not expose the connection > tracking - so that most of the internals would already be ready, and > implementing it after the merge would be trivial - either for me or anyone > else. >
Actually, as it's trivial(ish), I'd prefer doing it before the merge. Otherwise, I don't think anybody is going to do it in the near future, but rather re-implement updating the set in their applications... Thinking about it, the exposed tracking data structure should probably be a map from (connection id) to struct having accessors returning the contact and auth byte / source address, and the added signal should either include said struct (not exposing a bare variant parameter) or just the connection ID. If going for just the key (connection id) in the signal, there should be a guarantee that the signal is always emitted after the corresponding info is added to the map. In any case, there should be a guarantee that the removed signal is emitted before the info is removed from the map, so the app can take a look at the contact closing the connection etc without their own tracking. > > Definitely :) thanks for the thorough review. > > P.S.: Will send a new alert when all of those issues have been addressed and I > will commit new fixes as new commits. > > -- > ------------------- > > Dario Freddi > KDE Developer > GPG Key Signature: 511A9A3B > Cool, thanks! -- Br, Olli Salli _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
