I meant to reply sooner, and got sidetracked with other things... On Thu, 30 Sep 2010 07:28:39 -0400, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Wed, Sep 29, 2010 at 10:57:30PM -0400, Benjamin Johnson wrote:
On Wed, 29 Sep 2010 21:22:43 -0400, Jorge Arellano Cid <jcid@dillo.org> wrote:
The dpi framework works with isolated processes. A third option could be to make an alternative implementation that works in Win. For instance, is there a dbus port running in Win*?
There is, although I have a couple reservations. I'm not sure how cleanly it could be packaged, or whether it would run on Windows 9x (one of my goals is to support all the way back to Windows 95). I also have some personal dislike for it, after dealing with much dbus-related breakage in my Linux development days.
I do appreciate the suggestion, though, and if you think it could work, I will certainly look into it.
I haven't used dbus, but it's used in GNU/Linux by some big players so I guess it stabilized [1]. Any inter process message- passing lib will work, but implementing it well is a hard task, that's why I suggested dbus (it has undergone lots of testing). Probably there's a better candidate in the embedded area.
My problem with dbus isn't so much stability, as complexity. It's been a while since I've run Linux, but I vaguely remember dbus's internal security/permissions were a nightmare. I'll admit, I'm not the biggest fan of DPI anyway -- relying on complex interprocess communication even for such simple things as local file browsing seems like more trouble than it's worth. It's better than the other way around, re-implementing operating system functionality inside the browser (as a certain search giant has), but I'm not yet convinced the advantages truly outweigh the implementation hassles.
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?"
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? ~Benjamin