> With respect I don't think that suggests that Polipo is unmaintainable.
[...] > Anyway, I digress. Having read through the source code to Polipo and > produced patches to it I would say that while sometimes following the > control flow was slightly challenging this was offset by [...] Thanks for the kind words. However, I am pretty positive that some parts of Polipo are a mess. When I started working on Polipo, I had just left the XFree86 project; after four years of having to keep your code as simple as feasible (crashing the X server is just not an option), I was dying to do complicated things. Polipo is an extremely efficient design (every single algorithm used is in O(log n)) , but some parts are way more complicated than they could be -- look at the code that handles POST requests, for instance. > Sometimes it seems to me that the academia likes to focus on certain > aspects such as static analysis, provable correctness, etc. whereas it > will ignore some of the less glamorous engineering realities that make > building, and especially maintaining software difficult. While what you're saying true in general, it's certainly not true of the work of Boutier and Kerneis. CPC is actually originally my work, and this latest paper is a continuation of some work that I supervised [1] (with hindsight, I should have been co-author of this paper too to avoid any misunderstandings). In designing CPC, I've tried to the extent possible to respect these practical considerations that you mention: - no external dependencies; - minimal runtime; - possible to write your own event loop; - no need for a garbage collector; - the programmer is in control -- no global analysis performed by the translator, no automatic decisions about whether to use native or cooperative threads. Of course, you need to depend on the CPC compiler, which is almost, but not quite, architecture-independent (we've ported it to Linux/i386, Linux/AMD64, Linux/MIPS with very little effort, and to Windows/i386 with a little more work), but that's probably unavoidable if you want to make hybrid programming easy. (Kerneis has broken some of these properties, notably by making CPC dependent on Cil and on libev, but I still feel that the current incarnation of CPC is pretty close to the original vision.) I've been toying with the idea to reimplement Polipo in CPC, but we decided to move on to other protocols instead (we implemented Hekate[2]). > * The lack of automated tests. Agreed. However, the parts of Polipo that are difficult to get right wouldn't be helped by automated tests -- error handling, in particular, and robustness in the face of race conditions. > * The fact that the current master branch is not release worthy and only > you know why I think I've mentioned this already -- the local interface is broken, there's a race condition somewhere. Fixing that is probably not a big job, but I feel little motivation to take a couple of days off to do that until somebody volunteers to act as release manager; if I finish it now, I'll be under pressure to make a release myself, and I just don't have time for that nowadays. > (as would writing it in some other language which translates to C such > as vala) Vala is very different from CPC. Vala uses a fairly heavy runtime, while CPC's runtime is just a thousand lines of C -- basically Polipo's event.c plus a simple and efficient event loop (written by myself, in the style you seem to appreciate). > I therefore think that that makes Polipo *better* as it is than as it > could be as described in the paper. That brings us to a different issue -- which is how I would write Polipo now, with all that I've learnt over the years. But I've bored you enough already. Thanks again for the kind words, -- Juliusz [1] http://www.pps.univ-paris-diderot.fr/~jch/research/cpc-2012.pdf [2] http://www.pps.univ-paris-diderot.fr/~jch/software/hekate/ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Polipo-users mailing list Polipo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/polipo-users
