[Telepathy] API Draft for high level tubes in tp-qt4

[Olli Salli]

On Tue, Jun 1, 2010 at 3:47 PM, Dario Freddi <drf54321 at 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