mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

blog for the day

Browse source
This commit is contained in:
Joey Hess 2012-10-28 16:53:38 -04:00
parent 4ac2fd0a22
commit ebb63e8038
2 changed files with 41 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

41
doc/design/assistant/blog/day_117__new_topologies.mdwn Normal file
View file

@ -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.

8
doc/design/assistant/xmpp.mdwn
View file

@ -4,16 +4,8 @@ who share a repository, that is stored in the [[cloud]].
### TODO ### TODO
* Nudge user to enable XMPP account at appropriate times, ie, after configuring
cloud remotes.
* Prevent idle disconnection. Probably means sending or receiving pings, * Prevent idle disconnection. Probably means sending or receiving pings,
but would prefer to avoid eg pinging every 60 seconds as some clients do. 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 * XMPP pairing
## design goals ## design goals