1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
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.
|
