From ce2b5e8c0cb8ab937e9ca06c3ec4567fa62d653c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 6 Nov 2012 16:36:58 -0400 Subject: [PATCH] blog for the day --- ...ay_124__git_push_over_xmpp_groundwork.mdwn | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn diff --git a/doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn b/doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn new file mode 100644 index 0000000000..ecb6023f20 --- /dev/null +++ b/doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn @@ -0,0 +1,28 @@ +Laying the groundwork for git push over XMPP. BTW, the motivation for doing +this now is that if the assistant can push git data peer-to-peer, users +who are entirely using the cloud don't need to set up a git repo in the +cloud somewhere. Instead, a single special remote in the cloud will be all +they need. So this is a keystone in the assistant's cloud support. + +I'm building the following pipeline: + + git push <--> git-annex xmppgit <--> xmppPush <-------> xmpp + | + git receive-pack <--> xmppReceivePack <---------------> xmpp + +A tricky part of this is `git-annex xmppgit`, which is run by `git push` +rather than the usual `ssh`. Rather than speak XMPP itself, that feeds the +data through the assistant daemon, using some special FDs that are set +up by the assistant when it runs `git push`, and communicated via +environment variables. I hoped to set up a pipe and not need it to do any +work on its own, but short of using the linux-specific `splice(2)`, that +doesn't seem possible. It also will receive the exit status of +`git receive-pack` and propigate it to `git push`. + +Also built the IO sides of `xmppPush` and `xmppReceivePack` although these +are not tested. The XMPP sides of them come next. + +---- + +Stuffing lots of git-annex branded USB keys into envelopes tonight, while +watching the election coverage.