John Myers ([EMAIL PROTECTED]) scribbled: [snip to nuts and bolts] > eprogress - a general-purpose hierarchical progress reporting system > > my vision of the architecture has three components: > > 1) eprogress progress providers (clients?) (perhaps through some sort of > libeprogressc). These are programs like emerge, make, gcc, etc. which have > some sort of goal, and can report on their progress. They would need to be > patched to provide the system with the progress information.
I would advise against any development path that required patching many different projects. There would be a lot of resistance. This also seems to be passing off the crux of the problem (determining length of compile time) to the developers of make/gcc/ldd etc. See BUs, below. > 2) eprogressd (one for each master task, i.e. if you had an emerge and some > other make running at the same time, they would be kept separated). the > eprogressd would run in the background and keep track of all the progress > data. Why not a single daemon which spawns a thread for each new program, ala sshd (although iirc sshd forks)? > 3) eprogress viewers which communicate with eprogressd to display a > representation of the progress data. There could be any number of > interchangeable viewers, some for console, some for X11. Some may be > specialized to a particular task (such as a special one for emerges), but all > would use the same protocol to talk to the eprogressd, which would be kept > generic (there could (should?) be some sort of libeprogressviewer to help > with this) gkrellm? > I would suggest that the system should use UNIX domain sockets or TCP/IP > sockets for the communication, especially TCP/IP for the viewer connection. > It should not be necessary for the viewer to reside on the same machine as > the daemon. Nor, for that matter, should it be necessary for individual tasks > to be performed on the same machine. Good idea, but there is no need to suggest, it's your project :) > Also, progress information does not have to be limited to a percentage > (though > that is required). The information could contain many things, like compiler > command lines, warnings, errors, einfos etc. This is the line item requirement I would drive a truck through, if I were a customer/user. :) > Please let me know what you think. This idea has been floated many times before, with little success. Not to rain on the idea. :) The problem is much more complicated than it initially looks. For insight, take a look at the section in linuxfromscratch regarding SBUs (static bash units). http://archive.linuxfromscratch.org/lfs-museum/4.0/LFS-BOOK-4.0-HTML/chapter02/aboutsbus.html Personally, I would do less planning and more writing, some of the best projects started off as a hack to scratch an itch. Keep it simple. A lot of the most useful programs out there are very small. It can always be rewritten later to include TCP/IP or threads. Good luck! Cooper. -- gentoo-user@gentoo.org mailing list
