Hello, The patch was downloaded 14 times, and zero feedback... Great. I wanted to cleanup http.c in a similar way, but never mind. I feel sad and frustrated because of the lack of feedback from the Dillo developers. I tried to improve Dillo, to add some extra features. Dillo is a nice browser and I thought that spending my time on it would be appreciated, but it seems I was wrong. I give up, I'm not going to waste my time on improving Dillo while all efforts are just ignored or told to be useless because of the "that mess is fine as it is now" attitude. If the neutral and obviously (somehow I start doubting that now) improving IO cleanup patch is ignored, then what chance do I have with cleaning up the CCC horror... To give you an idea how bad it is: There are at least 24 ways of calling a ccc function. That is a conservative estimation, because I only counted the possible parameter combinations (values, types), you still need to know which variant of the many you need to use with a certain module. Also I counted only the ccc functions of the IO, cache, file, http and dns module, I didn't count the dpi and capi modules (just didn't come that far). This mess means that modules can't communicate transparantly with eachother, because they need to know exactly which data to give, implicating that they need to know with which module they're talking. That makes the whole CCC construction worthless, because one of it goals, or so I guess, was to have a chain like communication where linked elements could do their's stuff and notify the next element without knowing anything specific about eachother. With the current situation the CCC structure only adds unnecessary complexity to the overall code, obfuscating it. If that's what you want, fine, but then say so, instead of saying that it's hard to replace. Yes, duh, you made a spaghetti mountain, of course it's hard to clear that up. I truly hope that the rest of Dillo is cleaner, and from what I saw of it, the GUI part doesn't look that bad. Next grief: DPI's. What was meant like a simple plugin system turned out to become the sauce over the spaghetti, to stay with the previous metaphor. It seems like the cache api code handles dpi's differently, at least there is plenty dpi specific code in the capi.c file, so it seems like it's in the wrong place. I mean, if it's not part of the cache api, then what is it doing in that file? capi.c has even it's own CCC function only for dpi's, so an extra module in a wrapper?? Worst is, making a dpi isn't as simple as making a CGI, as it should be. And of course the whole dpid construction makes no sense. not really anyway: you can find all the dpi's the same way as you find the dpid... Sure, dpid has some minor advantages, but everyhting has _some_ advantages. All the dpi code (not including bookmarks.c) is 14K big, just imagine what you could implement with so much code (native ftp support comes into mind). Not even talking about how much resources the dpi's use, because they have such an awkward interface and need to do things that Dillo already could do, duplicating code and features. I'm aware that certain people already wasted too much time on the current dpi code, so it has zero chance of being changed, I'm not so naive to think it would. I just give my oppinion on it. I had put my hope on the IO/CCC mess. Sigh, if only Dillo went the GTK2 way, then I could say goodbye without trouble, but now it seems like Dillo will use FLTK it's even more depressing. --- Oh well, enough rambling, if someone wants an updated version of the installer, then say so. I won't do much with the https patch, because as it is now it can't be improved much without cleaning up IO, CCC or/and http, or at least without merging the IOData structures, so more than synching with CVS and tiny changes won't happen. Good luck and take care, Indan