On Sat, Oct 02, 2010 at 03:55:32PM -0400, Benjamin Johnson wrote:
On Sat, 02 Oct 2010 15:27:30 -0400, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
I like them and actually there is no way around it. One great feature of dillo is that you can fire up multiple processes very fast and still have access to the same bookmarks and cookies.
(1) Can't that be implemented without a separate server process?
Sure, you can use flock() or something like that. I think we even had this for cookies some time ago. But you get stale locks and all that. A separate process is the cleaner solution imho.
(2) Is there any reason to run multiple Dillo processes, anyway?
Yes. There are lots of reasons actually. Here are some: * You have separate caches. Stopping one process frees the cache and deletes the history of that process. * If one process crashes the other one continues. That's what google seems to do now with chrome. Dillo had this feature much earlier. * You could have multiple dillo instances on separate X11 sessions.
(3) How does that affect other protocols (FTP, HTTPS, local file browsing?)
?
On a related note, is there any reason not to cut DPI out of the download system, i.e. just invoke a separate downloader process directly? I'm considering implementing that at least as a temporary solution, using my own self-contained download tool.
The default downloader is a separate process. Before it, we used a call to wget from a separate process too. You're welcomed to hook your own preferred application, that's the idea of dpi.
Well, I meant that more in the sense of "since the downloader's a separate process anyway, why go through DPI at all?"
Well, we have all the infrastucture for DPI already, why use a new mechanism?
What's the advantage to doing it through DPI, besides that the infrastructure's already there?
See above.
Despite its perceived redundancy, my mechanism is ultimately simpler, since there's no interprocess communication involved. It's also a bit more efficient, since it cuts out the middleman (dpid).
I think the efficency argument doesn't count here. If you start a download, the single IPC to the DPI is certainly not an issue.
I think, by the way, there *are* clear advantages to a separate downloader: among other things, it allows downloads to continue after the user exits the browser. On the other hand, I don't see why the user would need cookies after the browser has exited.
Again, see above for reasons to have multiple dillo processes running.
Or is something more passed through than just a URL?
Maybe the target directory&savename. I don't remember well... You can make the dpip functions log the messages to a file without much hassle, and see what actually happens.
I wrote my own downloader, and patched Dillo so it calls my program directly, bypassing DPI. (It also bypasses the Dillo file dialogs, since my program displays its own.) So far everything seems to be working nicely.
I've only implemented the patch for Windows so far, and it needs a bit of cleanup, but if you're curious you can see it here: http://dillo-win32.sourceforge.net/files/dillo-r1705-dlgui-20100930.diff
and the downloader itself: http://dillo-win32.sourceforge.net/dlgui.html
I'm tempted to port Dillo to libcurl now, since it works so nicely in my own program, and seems like it would be much more portable (and stable, on Windows) than the current implementation. It would also allow for easier implementation of other protocols, like HTTPS and FTP. Any thoughts?
Hm, sounds like a massive change in a core component, but feel free to experiment.
Well, I've already done one of those with dsock, so why not another? :-)
Do you plan to get the windows port into dillo mainline, or do you want to maintain it as a patch? If you plan to get it in, I would suggest to focus on getting in what you have before doing other stuff. 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. * 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). * 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? * 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? Cheers, Johannes