summaryrefslogtreecommitdiff
path: root/Assistant.hs
Commit message (Collapse)AuthorAge
* 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
|
* better handling of lifting from XMPP -> AssistantGravatar Joey Hess2012-11-05
|
* XMPP pair requests are now received, and an alert displayedGravatar Joey Hess2012-11-03
|
* refactor XMPP clientGravatar Joey Hess2012-11-03
|
* split remaining assistant typesGravatar Joey Hess2012-10-30
|
* moved ThreadedMonad to TypesGravatar Joey Hess2012-10-29
|
* Assistant monad, stage 3Gravatar Joey Hess2012-10-29
| | | | | | All toplevel named threads are converted to the Assistant monad. Some utility functions still need to be converted.
* converted 2 more threads.. only 2 more to goGravatar Joey Hess2012-10-29
|
* tweakGravatar Joey Hess2012-10-29
|
* converted 6 more threadsGravatar Joey Hess2012-10-29
|
* convert Watcher thread to Assistant monadGravatar Joey Hess2012-10-29
| | | | | | | | | This is a nice win; much less code runs in Annex, so other threads have more chances to run concurrently. I do notice that renaming a file has gone from 1 to 2 commits. I think this is due to the above improvement letting the committer run more frequently, so it commits the rm first.
* Assistant monad, stage 2.5Gravatar Joey Hess2012-10-29
| | | | | | | | | | Converted several threads to run in the monad. Added a lot of useful combinators for working with the monad. Now the monad includes the name of the thread. Some debugging messages are disabled pending converting other threads.
* Assistant monad, stage 1Gravatar Joey Hess2012-10-29
| | | | | This adds the Assistant monad, and an AssistantData structure. So far, none of the assistant's threads run in the monad yet.
* more indentation. must stop.Gravatar Joey Hess2012-10-28
|
* ensure that git-annex branch is pushed after a successful transferGravatar Joey Hess2012-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I now have this topology working: assistant ---> {bare repo, special remote} <--- assistant And, I think, also this one: +----------- bare repo --------+ v v assistant ---> special remote <--- assistant While before with assistant <---> assistant connections, both sides got location info updated after a transfer, in this topology, the bare repo *might* get its location info updated, but the other assistant has no way to know that it did. And a special remote doesn't record location info, so transfers to it won't propigate out location log changes at all. So, for these to work, after a transfer succeeds, the git-annex branch needs to be pushed. This is done by recording a synthetic commit has occurred, which lets the pusher handle pushing out the change (which will include actually committing any still journalled changes to the git-annex branch). Of course, this means rather a lot more syncing action than happened before. At least the pusher bundles together very close together pushes, somewhat. Currently it just waits 2 seconds between each push.
* (re)start XMPP when it's configured in the webappGravatar Joey Hess2012-10-27
|
* typoGravatar Joey Hess2012-10-26
|
* gnutls segfault fixedGravatar Joey Hess2012-10-26
| | | | | | | | Adjust build deps to ensure that only a fixed version of the library will be used. Also, removed the bound thread stuff, which I now think was (probably) a red herring.
* better bound threadGravatar Joey Hess2012-10-25
|
* convert the assistant to use a bound thread for XMPPGravatar Joey Hess2012-10-25
| | | | | | | | | | | | | | | | | | This *may* solve the segfault I was seeing when the XMPP library called startTLS. My hypothesis is as follows: * TLS is documented (http://www.gnu.org/software/gnutls/manual/gnutls.html#Thread-safety) thread safe, but only when a single thread accesses it. * forkIO threads are not bound to an OS thread, so it was possible for the threaded runtime to run part of the XMPP code on one thread, and then switch to another thread later. So, forkOS, with its bound threads, should be used for the XMPP thread. Since the crash doesn't happen reliably, I am not yet sure about this fix. Note that I kept all the other threads in the assistant unbound, because bound threads have significantly higher overhead.
* initial implementation of XMPP push notifier (untested)Gravatar Joey Hess2012-10-24
| | | | | | | Lacking error handling, reconnection, credentials configuration, and doesn't actually do anything when it receives an incoming notification. Other than that, it might work! :)
* avoid building pushnotifier when there's no xmpp library installedGravatar Joey Hess2012-10-24
|
* added push notifier thread, currently a no-opGravatar Joey Hess2012-10-24
| | | | | | | | | | | Hooked up everything that needs to notify on pushes. Note that syncNewRemote does not notify. This is probably ok, and I'd need to thread more state through to make it do so. This is only set up to support a single push notification method; I didn't use a NotificationBroadcaster. Partly because I don't yet know what info about pushes needs to be communicated, so my data types are only preliminary.
* push out config changesGravatar Joey Hess2012-10-21
|
* add ConfigMonitor threadGravatar Joey Hess2012-10-20
| | | | | | | | | | | | | | | | | | | | Monitors git-annex branch for changes, which are noticed by the Merger thread whenever the branch ref is changed (either due to an incoming push, or a local change), and refreshes cached config values for modified config files. Rate limited to run no more often than once per minute. This is important because frequent git-annex branch changes happen when files are being added, or transferred, etc. A primary use case is that, when preferred content changes are made, and get pushed to remotes, the remotes start honoring those settings. Other use cases include propigating repository description and trust changes to remotes, and learning when a remote has added a new special remote, so the webapp can present the GUI to enable that special remote locally. Also added a uuid.log cache. All other config files already had caches.
* build fix for non-webapp enabled buildGravatar Joey Hess2012-09-23
|
* when a Download finishes, queue UploadsGravatar Joey Hess2012-09-18
| | | | | | | | | | | | | | | | | | | This ensures file propigate takes place in situations such as: Usb drive A is connected to B. A's master branch is already in sync with B, but it is being used to sneakernet some files around, so B downloads those. There is no master branch change, so C does not request these files. B needs to upload the files it just downloaded on to C, etc. My first try at this, I saw loops happen. B uploaded to C, which then tried to upload back to B (because it had not received the updated git-annex branch from B yet). B already had the file, but it still created a transfer info file from the incoming transfer, and its watcher saw that be removed, and tried to upload back to C. These loops should have been fixed by my previous commit. (They never affected ssh remotes, only local ones, it seemed.) While C might still try to upload to B, or to some other remote that already has the file, the extra work dies out there.
* deferred downloadsGravatar Joey Hess2012-09-17
| | | | | | | | | | | | | Now when a download is queued and there's no known remote to get it from, it's added to a deferred download list, which will be retried later. The Merger thread tries to queue any deferred downloads when it receives a push to the git-annex branch. Note that the Merger thread now also forces an update of the git-annex branch. The assistant was not updating this branch before, and it saw a (mostly) correct view of state, but now that incoming pushes go to synced/git-annex, it needs to be merged in.
* hlintGravatar Joey Hess2012-09-13
|
* pairing probably works now (untested)Gravatar Joey Hess2012-09-10
|
* first pass at alert buttonsGravatar Joey Hess2012-09-08
| | | | | | | | | They work fine. But I had to go to a lot of trouble to get Yesod to render routes in a pure function. It may instead make more sense to have each alert have an assocated IO action, and a single route that runs the IO action of a given alert id. I just wish I'd realized that before the past several hours of struggling with something Yesod really doesn't want to allow.
* added pair listener threadGravatar Joey Hess2012-09-08
|
* display errors when any named thread crashesGravatar Joey Hess2012-09-06
|
* fix build without the webappGravatar Joey Hess2012-08-30
|
* add download progress polling threadGravatar Joey Hess2012-08-28
|
* add NetWatcher threadGravatar Joey Hess2012-08-21
| | | | | | This deals with interruptions in network connectevity, by listening for a new network interface coming up (using dbus to see when network-manager or wicd do it), and forcing a rescan of
* implement resuming of paused transfersGravatar Joey Hess2012-08-12
| | | | | Currently waits for a new transfer slot to open up, which probably needs to change..
* wire up scan and transfer to newly added removable driveGravatar Joey Hess2012-08-04
| | | | remote setup still todo
* start webapp thread earlier so it opens ASAPGravatar Joey Hess2012-08-02
|
* fix the watch command to not run the whole assistantGravatar Joey Hess2012-08-01
| | | | heh :)
* write pid file even when running in foregroundGravatar Joey Hess2012-08-01
| | | | | | | | This prevents multiple runs of the assistant in the foreground, and lets --stop stop foregrounded runs too. The webapp firstrun case also now writes a pid file, once it's made the git repo to put it in.
* implemented firstrun repository creation and redirection to full webappGravatar Joey Hess2012-08-01
| | | | Some of the trickiest code I've possibly ever written.
* webapp now starts up when run not in a git repoGravatar Joey Hess2012-07-31
|
* add more alertsGravatar Joey Hess2012-07-29
| | | | Nearly all long-running actions now display an alert.
* send notifications when the TransferQueue is changedGravatar Joey Hess2012-07-28
| | | | | | The fun part was making it move things from TransferQueue to currentTransfers entirely atomically. Which will avoid inconsistent display if the WebApp renders the current status at just the wrong time. STM to the rescue!
* move DaemonStatus manipulation out of the Annex monad to IOGravatar Joey Hess2012-07-28
| | | | | | I've convinced myself that nothing in DaemonStatus can deadlock, as it always keepts the TMVar full. That was the only reason it was in the Annex monad.
* much better webapp startup of the assistantGravatar Joey Hess2012-07-27
| | | | | | This avoids forking another process, avoids polling, fixes a race, and avoids a rare forkProcess thread hang that I saw once time when starting the webapp.
* add warning when building without the webappGravatar Joey Hess2012-07-27
|
* webapp now displays the real running and queued transfersGravatar Joey Hess2012-07-27
| | | | yowza!!!