On 4/8/15, [email protected] <[email protected]> wrote: > Is anyone interested in a diff with this functionality? I don't mind > digging into the code, but I don't want to waste my time if it goes > against a core idea of Fossil. I'd just like the option of using it > with nothing external-facing other than SSH. >
This does not go against any core Fossil ideas. I just think it might be tricky to implement. The way the web interface works is that each HTTP request is handled by a separate process. In other words, a new "fossil" process is forked for each incoming HTTP request. That subprocess receives the HTTP request (in your case a ticket update) and then sends a reply back to the client, and then exits. The change you propose would be that the subprocess continues running after sending the HTTP reply and does a sync to its registered server (if it has one). Some potential problems: (1) How do you handle errors? The HTTP reply has already been sent. There is no way to notify the user that something went wrong. (2) If you try to deal with (1) by delaying the HTTP reply until after the sync takes place, then a slow sync will seriously delay the HTTP reply, which will make the interface seem to "freeze" form the point of view of the user. (3) Depending on how the subprocess was originally launched (CGI, SCGI, inetd, ssh, etc) the parent process might kill off the subprocess after receiving the HTTP reply, but before the subprocess has finished doing the sync. -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
