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

[Dario Freddi]

On Tuesday 01 June 2010 16:29:26 Olli Salli wrote:
> 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.

I'm not really getting that one. I have a

struct Connection {
ContactPtr contact,
QChar credByte,
QPair< QHostAddress, quint16 > addr
};

and credByte and addr should be populated according to what the variant in 
newRemoteConnection looks like. However, this is possible just in the outgoing 
connections, whereas in the incoming ones you would be able to track only the 
connection ids. At the moment connections() is implemented in StreamTube, 
should I move it upwards to OutgoingStreamTube?

Also, if this happens, I am wondering whether to expose a UIntList 
connections() in IncomingStreamTube.

And just to end up, am I supposed to do error handling for accessors or is it 
up to the CM? Depending on the answer, it might make no sense to expose 
credentials and address.

> 
> > 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!

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20100602/91d16e47/attachment.pgp>