| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
Partition syncRemotes into ones needing git sync (ie, non-special remotes),
and ones needing data sync (ie, non-XMPP remotes).
|
|
|
|
|
|
| |
Noticed that when pairing, sometimes both sides start to push, and the other
side sends a PushRequest, and the two deadlock, neither doing anything.
(Timeout eventually breaks this.) So, let both run at the same time.
|
|
|
|
| |
This improves type safety.
|
|
|
|
|
|
| |
My reasoning is that StartingPush could be received after another push
starts being received, and it would be better to respond to it afterwards
than not.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It might even work, although nothing yet triggers XMPP pushes.
Also added a set of deferred push messages. Only one push can run at a
time, and unrelated push messages get deferred. The set will never grow
very large, because it only puts two types of messages in there, that
can only vary in the client doing the push.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This includes keeping track of which buddies we're pairing with, to know
which PairAck are legitimate.
|
|
|
|
|
| |
Along the way, significantly cleaned up Assistant.XMPP, and made XMPP
message decoding more efficient.
|
| |
|
|
|
|
|
|
|
|
| |
Maybe the spec allows it, but broadcasting self-directed presence info to
all buddies is just insane.
I had to bring back the IQ messages for self-pairing, while still using
directed presence for other pairing. Ugly.
|
| |
|
|
|
|
| |
Rest of pairing process still to do.
|
|
|
|
|
| |
This ensures that clients that have not sent presence in a while will show
up in the list.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Currently have three old versions of functions that more reworking is
needed to remove: getDaemonStatusOld, modifyDaemonStatusOld_, and
modifyDaemonStatusOld
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|