[Bug 24122] Move PEP code to Wocky

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24122





--- Comment #4 from Will Thompson <will.thompson at collabora.co.uk>  2009-09-24 06:02:07 PST ---
(In reply to comment #3)
> (In reply to comment #1)
> > Can you get more than one <item> in an event? My reading of XEP-0060
> > suggests you might. We should probably handle that case by calling the
> > handler callback n times?
> 
> Good point, but that shouldn't happen with PEP. Anyway, the new API doesn't
> have a callback anymore.

Okay, sure. I guess it's something to bear in mind.

> > <http://git.collabora.co.uk/?p=user/cassidy/telepathy-gabble;a=commitdiff;h=90cf6e92879906b62db2c2d03f336180e706c073>:
> > :(. I think this is much less clear than the code it replaces; I can't
> > see the content for the boilerplate.
> 
> Well that's how Sjoerd implemented _build in Wocky. If you think the Gabble API
> is better, feel free to open a Wocky bug to discuss improvements.

I'll do that.

> > Ditto the following patch, to a
> > slightly lesser extent, and make_publish_stanza().
> 
> Humm; I don't understand. What do you mean?

They're just further examples.

> > Why does wocky_pubsub_register_event_handler return an int, rather
> > than the PubsubEventHandler pointer (opaque, of course).
> 
> This was inspired from the porter register API. Anyway, this function doesn't
> exist in WockyPepService any more.

Okay, just wondered.

> > If the WockyPubsub is disposed with outstanding requests, do the
> > callbacks get called?
> > • If so, is the DBusGMethodInvocation still valid if the
> >   GabbleConnection it came from has died?
> >   • If so, we're safe, because the callbacks so far (at least in
> >     d4ad9554b0d3) don't use the conn if the request failed, but it
> >     feels accidental.
> >   • If not, we crash.
> > • If not, we leak.
> 
> It can't. The GSimpleAsyncResult has a ref on the source object so it can't be
> disposed while the operation is running.

Okay; so further to real life discussions, we need to make sure that
nothing will break if the callbacks fire after (eg) the
GabbleConnection's dead.

> > Asserting that priv->porter is non-NULL in
> > wocky_pubsub_send_query_async seems wrong: surely client code could
> > call this before the connection's connected?
> 
> Function now raises an error if there is no porter.

Looks good.

> > Does anything check the gboolean returned by
> > gabble_pubsub_event_handler()?
> 
> Yes; it tells to the stanza dispatcher if the handler actually handled the
> stanza or not.

Okay.

> > +  /* TODO: subscribe to node if needed */
> 
> I need the Wocky capabilities component to do that. Gabble still announce the
> +notify so it's fine for now.

Okay. Guess we should file a bug, blocked by the capabilities component.

> > I wonder if it'd be worth having a wrapper around the changed cb which
> > does the 'make a handle from the jid' stuff for you?
> 
> Not sure. In the Brand fully Wockified Gabble World; Gabble should use contacts
> objects.

I agree. In the meantime, helpers for handle↔jid conversions might be
good.

> > I enjoy how this branch makes a WockyPubsub, and then towards the end
> > stops directly using it. And then deletes it? What?!
> 
> Yeah, that's because after discussion we Sjoerd we decided to have a separated
> API for PEP and for Pubsub. I didn't re-record the branch as most of the
> changes were still useful in the new version and I didn't want to fight
> conflicts of the dead. :)

Okay, that's reasonable!


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