diff options
author | Joey Hess <joey@kitenet.net> | 2012-07-19 13:19:11 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2012-07-19 13:19:11 -0400 |
commit | c99710a31009820a80d99c8502ba2470b924dc1d (patch) | |
tree | 3ae0faf598ac883ad7b8bc058c9a269ff4a01e1c | |
parent | 21d35f88d88676f71ad7669b9dfe398e57d7731c (diff) |
blog for the day
-rw-r--r-- | doc/design/assistant/blog/day_40__dbus.mdwn | 100 |
1 files changed, 100 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_40__dbus.mdwn b/doc/design/assistant/blog/day_40__dbus.mdwn new file mode 100644 index 000000000..049c3ffe0 --- /dev/null +++ b/doc/design/assistant/blog/day_40__dbus.mdwn @@ -0,0 +1,100 @@ +Really productive day today, now that I'm out of the threaded runtime +tarpit! + +First, brought back `--debug` logging, better than before! As part of that, I +wrote some 250 lines of code to provide a IMHO more pleasant interface to +`System.Process` (itself only 650 lines of code) that avoids all the +low-level setup, cleanup, and tuple unpacking. Now I can do things like +write to a pipe to a process, and ensure it exits nonzero, this easily: + + withHandle StdinHandle createProcessSuccess (proc "git" ["hash-object", "--stdin"]) $ \h -> + hHutStr h objectdata + +My interface also makes it easy to run nasty background processes, +reading their output lazily. + + lazystring <- withHandle StdoutHandle createBackgroundProcess (proc "find" ["/"]) hGetContents + +Any true Haskellers are shuddering here, I really should be using +conduits or pipes, or something. One day.. + +---- + +The assistant needs to detect when removable drives are attached, and +sync with them. This is a reasonable thing to be working on at this point, +because it'll make the currently incomplete data transfer code fully usable +for the sneakernet use case, and firming that up will probably be a good +step toward handing other use cases involving data transfer over the +network, including cases where network remotes are transientely available. + +So I've been playing with using dbus to detect mount events. +There's a very nice Haskell library to use dbus. + +This simple program will detect removable drives being mounted, and +works on Xfce (as long as you have automounting enabled in its +configuration), and should also work on Gnome, and, probably, KDE: + +[[!format haskell """ +{-# LANGUAGE OverloadedStrings #-} + +import Data.List (sort) +import DBus +import DBus.Client +import Control.Monad + +main = do + client <- connectSession + + listen client mountadded $ \s -> + putStrLn (show s) + + forever $ getLine -- let listener thread run forever + + where + mountadded = matchAny + { matchInterface = Just "org.gtk.Private.RemoteVolumeMonitor" + , matchMember = Just "MountAdded" + } +"""]] + +(Yeah... "org.gtk.Private.RemoteVolumeMonitor". There are so +many things wrong with that string. What does gtk have to do with +mounting a drive? Why is it Private? Bleagh. Should I only match +the "MountAdded" member and not the interface? Seems everyone who does +this relies on google to find other people who have cargo-culted it, +or just runs `dbus-monitor` and picks out things. +There seems to be no canonical list of events. Bleagh.) + +---- + +Spent a while shaving a yak of needing a `getmntent` interface in Haskell. +Found one in a hsshellscript library; since that library is not packaged +in Debian, and I don't really want to depend on it, I extracted just +the mtab and fstab parts of it into a little library in git-annex. + +---- + +I've started putting together a MountWatcher thread. On systems without +dbus (do OSX or the BSDs have dbus?), or if dbus is not running, it polls +`/etc/mtab` every 10 seconds for new mounts. When dbus is available, +it doesn't need the polling, and should notice mounts more quickly. + +Open question: Should it still poll even when dbus is available? Some of us +like to mount our own drives, by hand and may have automounting disabled. It'd +be good if the assistant supported that. This might need a +`annex.no-dbus` setting, but I'd rather avoid needing such manual +configuration. + +One idea is to do polling in addition to dbus, if `/etc/fstab` contains +mount points that seem to be removable drives, on which git remotes lives. +Or it could always do polling in addition to dbus, which is just some extra +work. Or, it could try to introspect dbus to see if mount events will +be generated. + +The MountWatcher so far only detects new mounts and prints out what +happened. Next up: Do something in response to them. + +This will involve manipulating the Annex state to belatedly add the Remote +on the mount point.. tricky. And then, for Git Remotes, it should pull/push +the Remote to sync git data. Finally, for all remotes, it will need to +queue Transfers of file contents from/to the newly available Remote. |