On Sun, Oct 03, 2010 at 03:13:51PM -0400, Benjamin Johnson wrote:
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.
That's fine, but I fear nobody else will do the work for you.
* 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
I have missed that. But I still fail to see why we should need to wait until there is no more connection open - that could take ages.
* 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.
The bug is marked as resolved for fltk-1.3. I'd suggest to write a test program to check whether it works as you expect in fltk-1.3.
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 doubt that libcurl would be an option, but as I said, feel free to experiment. Cheers, Johannes