git-annex-gpl - git-annex without the AGPL

	Commit message (Collapse)	Author	Age
*	refactor XMPP client	Joey Hess	2012-11-03
\|
*	ignore our own client presence	Joey Hess	2012-11-02
\|
*	xmpp buddy list tracking	Joey Hess	2012-11-02
\|
*	finished pushing Assistant monad into all relevant files	Joey Hess	2012-10-30
\| \| \| \|	All temporary and old functions are removed.
*	cleanup daemonStatus accessors	Joey Hess	2012-10-30
\|
*	split remaining assistant types	Joey Hess	2012-10-30
\|
*	split out daemonstatus types	Joey Hess	2012-10-30
\|
*	split and lift Assistant.Pushes	Joey Hess	2012-10-29
\|
*	more lifting	Joey Hess	2012-10-29
\|
*	converted 6 more threads	Joey Hess	2012-10-29
\|
*	Assistant monad, stage 2.5	Joey Hess	2012-10-29
\| \| \| \| \| \| \| \| \| \|	Converted several threads to run in the monad. Added a lot of useful combinators for working with the monad. Now the monad includes the name of the thread. Some debugging messages are disabled pending converting other threads.
*	send git-annex tag in initial presence	Joey Hess	2012-10-28
\| \| \| \|	Will be used for finding other git-annex clients for pairing
*	reconnect XMPP when NetWatcher notices a change	Joey Hess	2012-10-27
\|
*	xmpp reconnection	Joey Hess	2012-10-27
\| \| \| \| \|	If it managed to run for 5 minutes, reconnect immediately. Otherwise, wait 5 minutes before reconnecting.
*	gnutls segfault fixed	Joey Hess	2012-10-26
\| \| \| \| \| \| \| \|	Adjust build deps to ensure that only a fixed version of the library will be used. Also, removed the bound thread stuff, which I now think was (probably) a red herring.
*	split out xmpp utilities	Joey Hess	2012-10-26
\|
*	run xmpp test in bound thread	Joey Hess	2012-10-26
\|
*	XMPP configuration form	Joey Hess	2012-10-26
\| \| \| \| \| \|	Currently relies on SRV being set, or the JID's hostname being the server hostname and the port being default. Future work: Allow manual configuration of user name, hostname, and port.
*	SRV record construction	Joey Hess	2012-10-26
\|
*	hook up SRV lookups for XMPP	Joey Hess	2012-10-26
\|
*	convert the assistant to use a bound thread for XMPP	Joey Hess	2012-10-25
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	This may solve the segfault I was seeing when the XMPP library called startTLS. My hypothesis is as follows: * TLS is documented (http://www.gnu.org/software/gnutls/manual/gnutls.html#Thread-safety) thread safe, but only when a single thread accesses it. * forkIO threads are not bound to an OS thread, so it was possible for the threaded runtime to run part of the XMPP code on one thread, and then switch to another thread later. So, forkOS, with its bound threads, should be used for the XMPP thread. Since the crash doesn't happen reliably, I am not yet sure about this fix. Note that I kept all the other threads in the assistant unbound, because bound threads have significantly higher overhead.
*	only use one push attribute	Joey Hess	2012-10-25
\| \| \| \| \|	When pushing to multiple UUIDs, combine them all into a single push attribute.
*	switch from presence toggle hack to git-annex tag in presence extended content	Joey Hess	2012-10-25
\| \| \| \|	Push notifications are actually working over XMPP now!
*	add a separate field for the JID	Joey Hess	2012-10-24
\|
*	flip availablility	Joey Hess	2012-10-24
\| \| \| \| \| \| \| \| \|	Seems presence notifications are not sent to clients that have marked themselves unavailable. (Testing with google talk.) This is the death knell for the presence hack, because it has to stay available, and even the toggle to unavailable and back could cause it to miss a notification. Still, flipped it so it basically works, for now.
*	pull from one of the remotes in a push notification	Joey Hess	2012-10-24
\| \| \| \| \|	Still need to do something about transfer queueing, however. This could be a real can of worms.
*	initial implementation of XMPP push notifier (untested)	Joey Hess	2012-10-24
\| \| \| \| \| \| \|	Lacking error handling, reconnection, credentials configuration, and doesn't actually do anything when it receives an incoming notification. Other than that, it might work! :)
*	added push notifier thread, currently a no-op	Joey Hess	2012-10-24
	Hooked up everything that needs to notify on pushes. Note that syncNewRemote does not notify. This is probably ok, and I'd need to thread more state through to make it do so. This is only set up to support a single push notification method; I didn't use a NotificationBroadcaster. Partly because I don't yet know what info about pushes needs to be communicated, so my data types are only preliminary.