summaryrefslogtreecommitdiff
path: root/Assistant
Commit message (Collapse)AuthorAge
* split Commits and liftedGravatar Joey Hess2012-10-29
|
* split Changes and liftedGravatar Joey Hess2012-10-29
|
* split BranchChange and liftedGravatar Joey Hess2012-10-29
|
* split ScanRemotes and liftedGravatar Joey Hess2012-10-29
|
* moved ThreadedMonad to TypesGravatar Joey Hess2012-10-29
|
* split and lift Assistant.PushesGravatar Joey Hess2012-10-29
|
* tweakGravatar Joey Hess2012-10-29
|
* lift alertWhileGravatar Joey Hess2012-10-29
|
* move alert display functionsGravatar Joey Hess2012-10-29
|
* more liftingGravatar Joey Hess2012-10-29
|
* remove brokendebugGravatar Joey Hess2012-10-29
|
* lifted Assistant.Sync into Assistant monadGravatar Joey Hess2012-10-29
| | | | lots of nice cleanups
* tweakGravatar 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.
* send git-annex tag in initial presenceGravatar Joey Hess2012-10-28
| | | | Will be used for finding other git-annex clients for pairing
* 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.
* add git-annex branch commit when assistant is syncingGravatar Joey Hess2012-10-28
| | | | Seems nothing else ensures the branch is committed anymore.
* add XMPP nudge alert, displayed after making a cloud repositoryGravatar Joey Hess2012-10-27
|
* add an icon for The CloudGravatar Joey Hess2012-10-27
| | | | | | | | | | | I am befuddled that Twitter Bootstrap has no built-in Icon for The Cloud, and also that Chromium's depiction of CLOUD (U+2601) has an uncanny resemblance to PILE OF POO (U+1F4A9) when rendered small, and looks like a looming Frankenstorm when rendered large, and not a sweet, sunny, nothing can go wrong The Cloud. <http://www.fileformat.info/info/unicode/char/2601/browsertest.htm> So, I must resort to irony in my choice of icons.
* (re)start XMPP when it's configured in the webappGravatar Joey Hess2012-10-27
|
* reconnect XMPP when NetWatcher notices a changeGravatar Joey Hess2012-10-27
|
* xmpp reconnectionGravatar Joey Hess2012-10-27
| | | | | If it managed to run for 5 minutes, reconnect immediately. Otherwise, wait 5 minutes before reconnecting.
* 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.
* Merge branch 'master' into xmppGravatar Joey Hess2012-10-26
|\ | | | | | | | | Conflicts: Assistant/Threads/NetWatcher.hs
| * NetWatcher: When dbus connection is lost, try to reconnect.Gravatar Joey Hess2012-10-26
| | | | | | | | | | | | | | | | MountWatcher can't do this, because it uses the session dbus, and won't have access to the new DBUS_SESSION_BUS_ADDRESS if a new session is started. Bumped dbus library version, FD leak in it is fixed.
* | split out xmpp utilitiesGravatar Joey Hess2012-10-26
| |
* | run xmpp test in bound threadGravatar Joey Hess2012-10-26
| |
* | XMPP configuration formGravatar Joey Hess2012-10-26
| | | | | | | | | | | | Currently relies on SRV being set, or the JID's hostname being the server hostname and the port being default. Future work: Allow manual configuration of user name, hostname, and port.
* | SRV record constructionGravatar Joey Hess2012-10-26
| |
* | hook up SRV lookups for XMPPGravatar Joey Hess2012-10-26
| |
* | Merge branch 'master' into xmppGravatar Joey Hess2012-10-26
|\| | | | | | | | | | | Conflicts: Assistant/Threads/MountWatcher.hs Assistant/Threads/NetWatcher.hs
| * improved dbus error handlingGravatar Joey Hess2012-10-26
| | | | | | | | | | | | | | Now when the dbus connection is dropped, it'll fall back to polling. I could make it try to reconnect, but there's a FD leak in the dbus library, so not yet.
| * Use USER and HOME environment when set, and only fall back to getpwent, ↵Gravatar Joey Hess2012-10-25
| | | | | | | | which doesn't work with LDAP or NIS.
* | 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.
* | only use one push attributeGravatar Joey Hess2012-10-25
| | | | | | | | | | When pushing to multiple UUIDs, combine them all into a single push attribute.
* | switch from presence toggle hack to git-annex tag in presence extended contentGravatar Joey Hess2012-10-25
| | | | | | | | Push notifications are actually working over XMPP now!
* | add a separate field for the JIDGravatar Joey Hess2012-10-24
| |
* | flip availablilityGravatar Joey Hess2012-10-24
| | | | | | | | | | | | | | | | | | Seems presence notifications are not sent to clients that have marked themselves unavailable. (Testing with google talk.) This is the death knell for the presence hack, because it has to stay available, and even the toggle to unavailable and back could cause it to miss a notification. Still, flipped it so it basically works, for now.
* | pull from one of the remotes in a push notificationGravatar Joey Hess2012-10-24
| | | | | | | | | | Still need to do something about transfer queueing, however. This could be a real can of worms.
* | 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! :)
* | 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.
* | use a newtype for better type safetyGravatar Joey Hess2012-10-24
|/
* webapp: Switched to using the same multicast IP address that avahi uses.Gravatar Joey Hess2012-10-22
|
* webapp: Allow dashes in ssh key comments when pairing.Gravatar Joey Hess2012-10-22
|