summaryrefslogtreecommitdiff
path: root/Assistant.hs
Commit message (Collapse)AuthorAge
* 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.
* remove overview of threads an mvarsGravatar Joey Hess2013-05-22
| | | | | has become too long to be useful, and I find I don't need it anymore to keep things straight
* reomove showStart, unnecessaryGravatar Joey Hess2013-05-09
|
* run checkCanWatch before redirecting errors to logGravatar Joey Hess2013-05-09
| | | | This was handled ok in daemon mode, but not in foreground mode.
* Detect systems that have no user name set in GECOS, and also don't have ↵Gravatar Joey Hess2013-04-22
| | | | user.name set in git config, and put in a workaround so that commits to the git-annex branch (and the assistant) will still succeed despite git not liking the system configuration.
* webapp: New --listen= option allows running the webapp on one computer and ↵Gravatar Joey Hess2013-04-08
| | | | | | | connecting to it from another. Does not yet use HTTPS. I'd need to generate a certificate, and I'm not sure what's the best way to do that.
* refactor alert button creation codeGravatar Joey Hess2013-04-04
|
* streamline deletion process and improve UIGravatar Joey Hess2013-04-03
|
* clean up urlrenderer handling when the webapp is not builtGravatar Joey Hess2013-04-03
|
* detect when unwanted remote is empty and remove itGravatar Joey Hess2013-04-03
| | | | Needs fixes to build when the webapp is disabled.
* hlintGravatar Joey Hess2013-04-03
|
* add a debug message about where logging goesGravatar Joey Hess2013-03-27
|
* add a startup notice in the log, with version numberGravatar Joey Hess2013-03-17
|
* tweakGravatar Joey Hess2013-03-12
|
* got hdevtools working on the git-annex source treeGravatar Joey Hess2013-03-12
|
* assistant: Logs are rotated to avoid them using too much disk space.Gravatar Joey Hess2013-03-01
| | | | | | This cannot completely guard against a runaway log event, and only runs every hour anyway, but it should avoid most problems with very long-running, active assistants using up too much space.
* fix build with webapp disabledGravatar Joey Hess2013-02-06
| | | | Broken by recent thread manager and restarting improvements.
* webapp: Now allows restarting any threads that crash.Gravatar Joey Hess2013-01-26
|
* use async to track and manage threadsGravatar Joey Hess2013-01-26
|
* webapp: Now always logs to .git/annex/daemon.logGravatar Joey Hess2013-01-15
| | | | | | | | It used to not log to daemon.log when a repository was first created, and when starting the webapp. Now both do. Redirecting stdout and stderr to the log is tricky when starting the webapp, because the web browser may want to communicate with the user. (Either a console web browser, or web.browser = echo) This is handled by restoring the original fds when running the browser.
* assistant: Detect when system is not configured with a user name, and set ↵Gravatar Joey Hess2013-01-06
| | | | environment to prevent git from failing.
* assistant: Retrival from glacier now handled.Gravatar Joey Hess2012-11-29
|
* 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-27 09:14:36 +0000