Nicolas Dumazet <nicdumz.commits@gmail.com> [Fri, 08 May 2009 12:19:57 +0900] rev 8557
inotify: Removing the unnecessary "inotifyserver" class variable.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Wed, 06 May 2009 01:40:03 +0900] rev 8556
inotify: set a flag so a failed inotify query doesn't get repeated.
If, for some reason, we can't get the inotify server to start, it's better to
disable inotify queries for the instance to avoid trying over and over to start
the server, which takes time. Just fall back on repo.status()
Nicolas Dumazet <nicdumz.commits@gmail.com> [Wed, 22 Apr 2009 00:37:35 +0900] rev 8555
inotify: introduce debuginotify, which lists which paths are under watch
Nicolas Dumazet <nicdumz.commits@gmail.com> [Wed, 22 Apr 2009 00:23:40 +0900] rev 8554
inotify: put STAT-specific query answer generation part in its own method
Nicolas Dumazet <nicdumz.commits@gmail.com> [Fri, 17 Apr 2009 20:10:47 +0900] rev 8553
inotify: change protocol so that different query types can be supported.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Tue, 07 Apr 2009 19:30:01 +0900] rev 8552
inotify: Separate query sending logic from Server starting.
Use a decorator around the public statusquery method of Client:
start_server(query_to_server):
try:
query_to_server()
except QueryFailed:
[error recovery, inotify Server (re)starting]
query_to_server()
This way, introducing a new xxxquery Client method is easy:
one has only to code the protocol part of xxxquery, ignoring errors,
and decorating it using start_server to handle server recovery
and (re)starts
Nicolas Dumazet <nicdumz.commits@gmail.com> [Tue, 07 Apr 2009 18:39:34 +0900] rev 8551
inotify: modular architecture for inotify clients
Put the socket init, query generation and response analysis in
a more generic client class.