presence: draft interface for Directed Presence management

[horazont]

TODO:

• Draft interface
• Discuss interface
• Implement
• Use with aioxmpp.muc

Fixes #213, fixes #212.

[horazont]

I’d like to get some feedback on the interface before I go about implementing it. Specifically:

• does this likely cover the MUC use cases?
• does this likely cover other use cases?
• will this be able to interact sanely with entitycaps?

[sebastianriese]

Looks good so far.

We have to think about the outbound presence filters, I think the directed presence should be in filter chain, perhaps we want an extra chain for directed presence to make it easier for services to work selectively.

[sebastianriese]

I believe this should take an initial presence as optional argument (so that you can already send a modified directed presence with the request).

[horazont]

That’s what muted=True is for. Workflow would be:

server = client.summon(PresenceServer)
handle = server.subscribe_peer_directed(some_peer, muted=True)
handle.presence_filter = …
handle.set_muted(False)

[sebastianriese]

My argument was less about the capability, but more about convenience of use, and conciseness of the code.

[horazont]

Right, but then I’d prefer to be able to set a presence_filter via the interface.

[sebastianriese]

When is the rebinding necessary? Do we direct presence to full JIDs? (Note: This is probably just my ignorance.)

[horazont]

Yes, we do for MUC. In MUC, you send directed presence to $bare_muc_jid/$nickname. When changing the nickname (either by choice or because the server forces you), you have to redirect the directed presence. Ugly, but that’s how it is.

[horazont]

We have to think about the outbound presence filters, I think the directed presence should be in filter chain, perhaps we want an extra chain for directed presence to make it easier for services to work selectively.

The directed presences pass through the outbound presence filter chain like any other presence. It is easy to detect, because it has a non-empty @to and a type of PresenceType.AVAILABLE or PresenceType.UNAVAILABLE.

I don’t think we need a specific filter chain for that, especially since the outbound/inbound stanza filters are on the StanzaStream level and the StanzaStream should not need to know the difference.

[sebastianriese]

Is directed presence with other types disallowed? Someone may need the capability to send a "busy" presence to their obnoxious relatives ;). I agree it is easy to detect, but I like pre-filtering if it deduplicates code and reduces the number of filter chain calls (by reducing the number of subscriptions).

However, your separation of layers argument makes sense.

[horazont]

A "busy" presence is type AVAILABLE with a specific <show/> child.

The other presence types are subscription related and not handled by PresenceServer.

[horazont]

@sebastianriese Mind to give this a review?

Somehow, the tight coupling between the DirectedPresenceHandle and the PresenceServer feels ugly. And also I assume that I’m missing some stuff here because I implemented this over the course of a few weeks with loooong breaks.

[sebastianriese]

I am opposed to call it presence_filter and not be an aioxmpp.callbacks.filter. (Why not use an aioxmpp.callbacks.Filter anyway?).

[horazont]

Kind of agreed on the nomenclature. Suggestions?

It is not a Filter object because the handle is under full control of a single object usually (in contrast to the filters on the stanza stream). If the single object needs to delegate control to multiple other things, it can do that by assigning a filter to that attribute.

[sebastianriese]

Perhaps we need even more special handling when sending directed presence to peers with from or both subscription (as the RFC specifies that those still receive presence broadcasts). So the current code sends the presence twice to those. (Probably we simply do not want to use this service with those we share subscription with due to the different processing by the server. This should be documented.)

[horazont]

We indeed need to document that care should be taken. It’s not as trivial as that, for example when stuff like XEP-0186 (Invisible Command) comes into play.

[sebastianriese]

Do we want this to happen in all cases? (e.g. to peers that are subscribed to our presence).