diff options
author | Joey Hess <joey@kitenet.net> | 2012-10-28 16:53:38 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2012-10-28 16:53:38 -0400 |
commit | 1a35e32c0702a554554d4d456b472db0286572bd (patch) | |
tree | 22d1a8b4a241cb2d773bdbe0cfee6fa9b13dee75 | |
parent | c8cd4ec3082ac7dd24c0377d66c95cb05b51f0ba (diff) |
blog for the day
-rw-r--r-- | doc/design/assistant/blog/day_117__new_topologies.mdwn | 41 | ||||
-rw-r--r-- | doc/design/assistant/xmpp.mdwn | 8 |
2 files changed, 41 insertions, 8 deletions
diff --git a/doc/design/assistant/blog/day_117__new_topologies.mdwn b/doc/design/assistant/blog/day_117__new_topologies.mdwn new file mode 100644 index 000000000..a205a90f4 --- /dev/null +++ b/doc/design/assistant/blog/day_117__new_topologies.mdwn @@ -0,0 +1,41 @@ +Back in [[day_85__more_foundation_work]], I wrote: + +> I suspect, but have not proven, +> that the assistant is able to keep repos arranged in any shape of graph in +> sync, as long as it's connected (of course) and each connection is +> bi-directional. [And each node is running the assistant.] + +After today's work, many more grap topologies can be kepy in sync -- the +assistant now can keep repos in sync that are not directly connected, but +must go through a central transfer point, which does not run the assistant +at all. Major milestone! + +To get that working, as well as using XMPP push notifications, it turned +out to need to be more agressive about pushing out changed location log +information. And, it seems, that was the last piece that was missing. +Although I narrowly avoided going down a blind alley involving sending +transfer notifications over XMPP. Luckily, I came to my senses. + +---- + +This month's focus was the cloud, and the month is almost done. And now +the assistant can, indeed be used to sync over the cloud! I would have +liked to have gotten on to implementing Amazon Glacier or Google Drive +support, but at least the cloud fundamentals are there. + +Now that I have XMPP support, I'm tending toward going ahead and adding +XMPP pairing, and git push over XMPP. This will open up lots of excellent +use cases. + +So, how to tunnel git pushes over XMPP? Well, `GIT_SHELL` can be set to +something that intercepts the output of `git-send-pack` and +`git-receive-pack`, and that data can be tunneled through XMPP to connect +them. Probably using XMPP ping. +(XEP-0047: In-Band Bytestreams would be the right way ... +but of course Google Talk doesn't support that extension.) + +XMPP requires ugly encoding that will bloat the data, but the data +quantities are fairly small to sync up a few added or moved files +(of course, we'll not be sending file contents over XMPP). Pairing with +an large git repository over XMPP will need rather more bandwidth, +of course. diff --git a/doc/design/assistant/xmpp.mdwn b/doc/design/assistant/xmpp.mdwn index 0241f09c0..291007f46 100644 --- a/doc/design/assistant/xmpp.mdwn +++ b/doc/design/assistant/xmpp.mdwn @@ -4,16 +4,8 @@ who share a repository, that is stored in the [[cloud]]. ### TODO -* Nudge user to enable XMPP account at appropriate times, ie, after configuring - cloud remotes. * Prevent idle disconnection. Probably means sending or receiving pings, but would prefer to avoid eg pinging every 60 seconds as some clients do. -* After pulling from a remote, may need to scan for transfers, which - could involve other remotes (ie, S3). Since the remote client is not able to - talk to us directly, it won't be able to upload any new files to us. - Need a fast way to find new files, and get them transferring. The expensive - transfer scan may be needed to get fully in sync, but is too expensive to - run every time this happens. Send transfer notifications using XMPP? * XMPP pairing ## design goals |