summaryrefslogtreecommitdiff
path: root/Assistant/NetMessager.hs
Commit message (Collapse)AuthorAge
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* fix some mixed space+tab indentationGravatar Joey Hess2014-10-09
| | | | | | | | | This fixes all instances of " \t" in the code base. Most common case seems to be after a "where" line; probably vim copied the two space layout of that line. Done as a background task while listening to episode 2 of the Type Theory podcast.
* clarify notifyNetMessagerRestartGravatar Joey Hess2013-08-24
|
* typoGravatar Joey Hess2013-05-26
|
* avoid redundant CanPush messages with different shas being queued upGravatar Joey Hess2013-05-26
|
* fix minor memory leak caused by recent CanPush changeGravatar Joey Hess2013-05-22
| | | | Putting the UUID in meant that equivilant CanPush messages no longer are ==
* add two long-running XMPP push threads, no more inversion of controlGravatar Joey Hess2013-05-22
| | | | | | | | | I hope this will be easier to reason about, and less buggy. It was certianly easier to write! An immediate benefit is that with a traversable queue of push requests to select from, the threads can be a lot fairer about choosing which client to service next.
* avoid building up a lot of threads all waiting for their chance to run a pushGravatar Joey Hess2013-05-22
| | | | | Only 2 threads are needed, one running, and one waiting to push something new. Any more is redundant and wasteful.
* per-client inboxes for push messagesGravatar Joey Hess2013-05-21
| | | | | | | | | | | This will avoid losing any messages received from 1 client when a push involving another client is running. Additionally, the handling of push initiation is improved, it's no longer allowed to run multiples of the same type of push to the same client. Still stalls sometimes :(
* XMPP: Be better at responding to CanPush messages when busy with something else.Gravatar Joey Hess2013-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Observed: With 2 xmpp clients, one would sometimes stop responding to CanPush messages. Often it was in the middle of a receive-pack of its own (or was waiting for a failed one to time out). Now these are always immediately responded to, which is fine; the point of CanPush is to find out if there's another client out there that's interested in our push. Also, in queueNetPushMessage, queue push initiation messages when we're already running the side of the push they would initiate. Before, these messages were sent into the netMessagesPush channel, which was wrong. The xmpp send-pack and receive-pack code discarded such messages. This still doesn't make XMPP push 100% robust. In testing, I am seeing it sometimes try to run two send-packs, or two receive-packs at once to the same client (probably because the client sent two requests). Also, I'm seeing rather a lot of cases where it stalls out until it runs into the 120 second timeout and cancels a push. And finally, there seems to be a bug in runPush. I have logs that show it running its setup action, but never its cleanup action. How is this possible given its use of E.bracket? Either some exception is finding its way through, or the action somehow stalls forever. When this happens, one of the 2 clients stops syncing.
* assistant: XMPP git pull and push requests are cached and sent when presence ↵Gravatar Joey Hess2013-03-06
| | | | | | | | | | | | | | | of a new client is detected. Noticed that, At startup or network reconnect, git push messages were sent, often before presence info has been gathered, so were not sent to any buddies. To fix this, keep track of which buddies have seen such messages, and when new presence is received from a buddy that has not yet seen it, resend. This is done only for push initiation messages, so very little data needs to be stored.
* todoGravatar Joey Hess2013-03-06
|
* update to dav 0.1, and basic uploading is working!Gravatar Joey Hess2012-11-15
|
* Fix build of assistant without yesod.Gravatar Joey Hess2012-11-13
|
* don't try to transfer data to/from XMPP remotesGravatar Joey Hess2012-11-11
| | | | | Partition syncRemotes into ones needing git sync (ie, non-special remotes), and ones needing data sync (ie, non-XMPP remotes).
* allow both one push and one receive-pack to run at the same timeGravatar Joey Hess2012-11-11
| | | | | | 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.
* show when a buddy is already pairedGravatar Joey Hess2012-11-10
|
* separate data type for push stagesGravatar Joey Hess2012-11-10
| | | | This improves type safety.
* fix deferring of CanPush, and stop deferring StartingPushGravatar Joey Hess2012-11-10
|
* xmpp push control flowGravatar Joey Hess2012-11-08
| | | | | | | | | 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.
* renameGravatar Joey Hess2012-11-08
|
* refactor XMPP clientGravatar Joey Hess2012-11-03