I have not looked at the source yet, but I think your explanation gives me a clear picture of the issues this would involve. This would need some sort of polling/persistent connection, and I'm not sure how well that meshes with Fossil's current web implementation.
This is somewhat OT, but I've been tackling a similar problem that may be of interest down the road. I had a project that required a small FCGI C server to serve up pages. Rather than compiling templates myself, I decided that I could make life easier by pushing that onto 3rd party JS libraries. What I ended up doing was creating a small FCGI C server that only dealt in JSON. I served up a static page, and rendered everything using AngularJS. I dislike JS as much as the next guy. However, I still feel that keeping the C simple makes the server cleaner and more auditable and the web UI more capable. I've only used Fossil for a week so far so take it for what it's worth, but it seems like a nice long-term direction for the web UI to follow something like this. On Wed, Apr 08, 2015 at 11:19:37AM -0400, Richard Hipp wrote: > 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 > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
