diff options
author | 2012-10-23 15:47:36 -0400 | |
---|---|---|
committer | 2012-10-23 15:47:36 -0400 | |
commit | 21612182c924686a6a5fd5f83600e768d8a646fd (patch) | |
tree | 2e4013b47de2b36a129df3c18aee93df40ccc24b /doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn | |
parent | 9b4ab3f9d39f2277902bbae434f9504b51158586 (diff) |
xmpp
Diffstat (limited to 'doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn')
-rw-r--r-- | doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn new file mode 100644 index 000000000..b7d72a275 --- /dev/null +++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn @@ -0,0 +1,50 @@ +Time to solve the assistant's [[cloud]] notification problem. This is +really the last big road-bump to making it be able to sync computers +across the big, bad internet. + +So, IRC still seems a possibility, but I'm going to try XMPP first. Since +Google Talk uses XMPP, it should be easy for users to get an account, and +it's also easy to run your own XMPP server. + +Played around with the Haskell XMPP library. Clint helpfully showed me an +example of a simple client, which helped cut through that library's thicket +of data types. In short order I had some clients that were able to see each +other connecting to my personal XMPP server. On to some design.. + +1. I want to avoid user-visible messages. + (dvcs-autosync also uses XMPP, but I checked the code and it + seems to send user-visible messages, so I diverge from its lead here.) + This seems very possible, only a matter of finding the right + way to use the protocol, or an appropriate and widely deployed extension. + The only message I need to send with XMPP, really, is "I have pushed to our + git repo". One bit of data would do; being able to send a UUID of the repo + that did the update would be nice. + +2. I'd also like to broadcast my notification to a user's buddies. + dvcs-autosync sends only self-messages, but that requires every node + have the same XMPP account configured. While I want to be able to run + in that mode, I also want to support pairs of users who have their own XMPP + accounts, that are buddied up in XMPP. + +3. To add to the fun, the assistant's use of XMPP should not make that XMPP + account appear active to its buddies. Users should not need a dedicated + XMPP account for git-annex, and always seeming to be available when + git-annex is running would not be nice. + +The first method I'm trying out is to encode the notification +data inside a XMPP presence broadcast. This should meet all three +requirements. The plan is two send two +presence messages, the first marks the client as available, and the second +as unavailable again. +The "id" attribute will be set to some +value generated by the assistant. That attribute is allowed on presence +messages, and servers are [required to preserve it](http://xmpp.org/rfcs/rfc6121.html#presence-probe-inbound-id) +while the client is connected. +(I'd only send unavailable messages, but while +that worked when I tested it using the prosody server, with google talk, +repeated unavailable messages were suppressed. Also, google talk does not +preserve the "id" attribute of unavailable presence messages.) + +If this presence hackery doesn't work out, I could try +[XEP-0163: Personal Eventing Protocol](http://xmpp.org/extensions/xep-0163.html). +But I like not relying on any extensions. |