On Sat, 10 Sep 2011, Richard Hipp wrote:
The hook mechanism should include a delay. This is because client-to-server
push operations can occur in multiple stateless steps, and we really want to
wait and
run the hooks after all steps of the push operation are complete. So, for example,
after the first push step, the server says to itself "I'm going to run the hooks
if I don't get any new information within 15 seconds." Then as additional
rounds of push arrive, the counter is reset. The 15-second wait interval should be
configurable.
I don't like timers like that, a single server may have clients on fast
connections 50 feet away, and at the end of a slow intercontinental link,
so setting the timer correctly is about impossible. On top of that:
they'll be hard to implement for cgi or inetd based servers, where nothing
is running unless a client has an open connection.
It's been a while since I looked at the protocol specs, but the client
usually maintains (implicit) state in this type of protocol, and could
very well indicate to the server that a push operation step is the first
one (for a pre-commit hook), last one (for a post-commit hook), or both,
which could then trigger the hooks immediately. Downsides:
- needs a protocol change
- what do you do if the last step never arrives?
Gé
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
