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? (2) Is there any reason to run multiple Dillo processes, anyway? (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? 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, 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.
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? :-) ~Benjamin