| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
XMPP has no defined message size limits, but some servers will have ad-hoc
limits. However, 4k seems safe, even after the additional bloat of base64.
That should not exceed 8k.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Various final bug fixes, and tweaks that got it working.
Currently pushes a hardcoded ref, which needs to be fixed, etc.
|
| | |
|
| |
|
|
|
| |
Took me a while to figure out why the xmpp client was not receiving git xmpp
push messages after a push started.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Inject the required git-remote-xmpp into PATH when running xmpp git push.
Rest of the time it will not be in PATH, and git won't be able to talk to
xmpp remotes.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It might even work, although nothing yet triggers XMPP pushes.
Also added a set of deferred push messages. Only one push can run at a
time, and unrelated push messages get deferred. The set will never grow
very large, because it only puts two types of messages in there, that
can only vary in the client doing the push.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Allow the tag to contain a value. Better extraction of the attribute value.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
But I could not find a way to implement it using just FD piping; it
has to copy the data.
|
| | |
|
| | |
|
| |
|
|
| |
shouldn't ever happen, but hey
|
| |
|
|
|
| |
This includes keeping track of which buddies we're pairing with, to know
which PairAck are legitimate.
|
| | |
|
| |
|
|
|
| |
Along the way, significantly cleaned up Assistant.XMPP, and made XMPP
message decoding more efficient.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Maybe the spec allows it, but broadcasting self-directed presence info to
all buddies is just insane.
I had to bring back the IQ messages for self-pairing, while still using
directed presence for other pairing. Ugly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Testing between Google Talk and prosody, the directed IQ messages
were not received. Google Talk probably only relays them between
clients using the same account.
I first tried even more directed presence, with each client JID being sent
a separate presence, but that didn't work on Google Talk, particularly
it was ignored when one client sent it to another client using the same
account.
So, presence directed at the user@host of the client to pair with. Tested
working between Google Talk and prosody (in both directions), as well
as between two clients with the same account on Google Talk, and
two clients with the same account on prosody.
Only problem with this form of directed presence is that if I also use it
for git pushes, more clients than are interested in a push's data will
receive it. So I may need some better approach, or a hybrid between
directed IQ and directed presence.
|
| |
|
|
|
|
|
|
|
| |
Amusingly, I am not really using xmpp ping for pairing. I forgot to put in
the ping tag! And when I did, it stopped working, on Google Talk. Seems
it handles client to client pings, at least using the same JID, without
actually sending them to the end client. My mistake avoided this,
and seems to work, so I've left it as-is for now, with just the git-annex
tag in an IQ message. Also tested on prosody.
|
| |
|
|
| |
it's not just about push notifications anymore
|
| | |
|
| |
|
|
| |
Rest of pairing process still to do.
|
| | |
|
| |
|
|
|
| |
This ensures that clients that have not sent presence in a while will show
up in the list.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
Joey Hess