On Sun, 03 Oct 2010 14:36:14 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
Do you plan to get the windows port into dillo mainline, or do you want to maintain it as a patch?
Getting it into Dillo mainline was always my intention. I do plan to maintain the SourceForge site for binary releases and other Windows-specific components, similar to GIMP for Windows.
If you plan to get it in, I would suggest to focus on getting in what you have before doing other stuff.
I'm just trying to look ahead, that's all. In a nutshell, I'm faced with some difficult technical hurdles, and somewhat a conflict of interests. On the one hand, I personally am not fond of DPI, and (as you've seen) question its necessity, particularly for such basic functionality as non-HTTP protocol support. On the other, my goal is (and has always been) to get my code into Dillo mainline, since I have neither the interest nor resources to maintain a full-blown fork.
That would mean:
* splitting up your patch into smaller chunks, each with a description of what it does and why it's needed. It should be obvious for each patch that it does what you described and only that.
I tried to do that already. The problem is that this is a very complicated patch, and all the individual "subpatches" are highly interdependent on one another. In order to effectively split the patch, I would essentially have to re-code each change manually, which I currently lack the time to do.
* Avoid any changes to the code base that are not necessary for the windows port (e.g. the include path changes in src/table.cc, or the fix for the race mentioned in html.cc - if you think there is a bug, this should be discussed on the list independent from the win port. The same for the change in decode.c).
I have not made a single change that is not necessary for the Windows port. The include path changes are necessary because MinGW does not accept them as written (relative to the top-level source directory). Regarding the race condition, that already *has* been discussed on the list, and the fix was specifically necessary for the Windows port: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-August/007652.html
* This iowatch kludge is nasty - as you also state in the comment. This must be fixed in some other way. Did you do some research on the fltk lists about this? Is this solved in fltk-1.3?
Yes, I did do research on the fltk lists -- that's how I discovered its necessity. To wit: http://www.mail-archive.com/fltk-bugs@easysw.com/msg01341.html Unfortunately, WSAAsyncSelect() doesn't appear to be the only problem. I patched the fltk source to disable USE_ASYNC_SELECT, to no avail. That's when I decided to implement the timeout kludge, in the interest of having *something* working, which I considered better than having nothing at all. I dislike the timeout kludge as well, since it's slow and extremely unstable, but as of yet have not found a workable alternative considering the current implementation. I haven't been able to dig further into fltk itself, due to lack of time and familiarity with the codebase (though I intend to someday, as there are some other things in there that need work, like popup menus on Windows 95). By the way, this is one reason I was interested in an alternate implementation using libcurl -- it would be much simpler than trying to implement low-level, cross-platform I/O ourselves.
* I don't like the DSOCK_NETINET_IN_H and similar defines to include the right files on each platform. Can't we always include dsock.h which in turn includes all necessary files?
I wasn't sure whether or not to do that, but I erred on the side of selectively including files since it seemed the more conservative option. If you don't like it, feel free to change it.
Cheers, Johannes
Cheers, ~Benjamin