[Bug 29458] TLS-connection branch

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 10 20:00:07 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=29458

--- Comment #2 from Cosimo Cecchi <cosimoc at gnome.org> 2010-08-10 11:00:07 PDT ---
(In reply to comment #1)
> In general I prefer the first review round for a branch to be a series of
> coherent patches (i.e. I prefer it if people use git rebase --interactive to
> squash trivial fixes into the patch that they fix, before the first review
> round; ideally, make check should pass and the code should make sense after
> each commit).
> 
> As a first review pass here I've mostly gone through the whole diff without
> looking at individual patches, so you're free to rebase where appropriate.
> There are changes in this branch that shouldn't be there, so please do rebase
> them out.

Ok, I will try to follow this workflow in the future.
In the meanwhile, I squashed and rebased my branch in logical pieces now, so
it's probably easier to follow. The URL is the same [1].

> > -  g_assert ((priv->state == JS_STATE_PENDING_CREATED) ||
> > -      (priv->state == JS_STATE_ENDED));
> > +  g_assert ((priv->state == (JingleState) JS_STATE_PENDING_CREATED) ||
> > +      (priv->state == (JingleState) JS_STATE_ENDED));
> 
> Likewise, and also, I don't like scattering casts through our code if we don't
> have to; they clutter the code (hurting clarity), and can mask genuine bugs
> that the compiler would have warned us about. I'll open a separate bug for the
> gcc 4.5 stuff.

Ok; I needed this for actual compilation, so it's just the first solution that
made code build. Anyway, I left it out of the branch, you can find the same
patch here for reference [2].

> Architectural thoughts
> ======================
> 
> I'm unhappy about subclassing WockyTLSHandler in the Channel; it means you
> can't subclass GabbleBaseChannel, so you need a lot of boilerplate. The
> many-one and one-one relationships also don't seem right this way.
> 
> Is there a reason why the *channel manager* can't be the WockyTLSHandler and do
> most of the work? If you did that, I think the architecture would make more
> sense:
> 
> * it could avoid creating the Channel until verify_async() is called, meaning
> the Channel could put itself on the bus, create its certificate, etc. in
> constructed() rather than having a separate method to do that
> * it could create a Channel every time verify_async() is called, if for some
> insane reason Wocky calls it multiple times

Great idea, I didn't think about this approach; the code indeed looks nicer and
cleaner now. I fixed my branch to follow this approach, except for your last
point (calling verify_async() multiple times from wocky), which should never
happen (so I special-cased that in my _verify_async() implementation).

> Minor details
> =============

I fixed all of your points, except for this

> > +      /* FIXME: this should be generated for us. */
> > +      array_of_ay_get_type (),
> 
> Don't you get GABBLE_ARRAY_TYPE_CERTIFICATE_DATA_LIST in
> extensions/_gen/gtypes.h?

No, it doesn't get generated. Probably a bug in the tp-parser code with array
tp:simple-types? Shall I file a bug for that?

[1]
http://git.collabora.co.uk/?p=user/cosimoc/telepathy-gabble.git;a=shortlog;h=refs/heads/tls-connection2
[2]
http://git.collabora.co.uk/?p=user/cosimoc/telepathy-gabble.git;a=shortlog;h=refs/heads/gcc4.5

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the telepathy-bugs mailing list