- Dillo-dev - lists.mailman3.com

Question about local file browsing

by rogutes＠googlemail.com

Benjamin Johnson (2011-04-09 14:17): <...snip...> > One other thing that concerns me: a Windows user might start Dillo, > see a bunch of unfamiliar DPI programs running, and worry that it's > some kind of virus/spyware infection. Even if someone explained > that it's just part of the browser, they might not be convinced, > since -- say -- Firefox doesn't start all that stuff in the > background. Spyware is increasingly a very real and very serious > concern, so many users are justifiably suspicious of anything even > remotely out of the ordinary. Firefox does start some stuff in the background (plugin-container.exe, since Firefox 3.6.4). Though your point seems to be valid, at least on Windows: http://google.com/search?q=plugin-container.exe -- -- Rogut?s Sparnuotos

April 9, 2011

Question about local file browsing

by obeythepenguin＠gmail.com

On Sat, 09 Apr 2011 13:52:43 -0400, corvid <corvid(a)lavabit.com> wrote: > Benjamin wrote: >> A much more practical solution, as far as I'm concerned, is simply to >> build that functionality into the browser: >> - It's simpler, since there's on interprocess communication required. >> - It's more portable, for the same reason. >> - It's easier to distribute, since you only need one executable. > > I personally like the idea of dillo in one piece. I think a lot of > people who give it a try don't get dillo + dpid + the dpis talking > to each other correctly, and then they don't want to waste their > time fighting with a random unfamiliar computer program. Personally, I'm not opposed to DPI in and of itself. I think it's an interesting extension mechanism, but I'd like it to remain just that -- a way of extending the browser. I don't think it should be used to offload major functionality that any reasonable user would expect to come built in. One other thing that concerns me: a Windows user might start Dillo, see a bunch of unfamiliar DPI programs running, and worry that it's some kind of virus/spyware infection. Even if someone explained that it's just part of the browser, they might not be convinced, since -- say -- Firefox doesn't start all that stuff in the background. Spyware is increasingly a very real and very serious concern, so many users are justifiably suspicious of anything even remotely out of the ordinary. Of course, I know I'm still in the minority here, which is why I just keep hacking away at it and try to let my code speak for itself. :-) ~Benjamin

April 9, 2011

Question about local file browsing

by corvid＠lavabit.com

Benjamin wrote: > A much more practical solution, as far as I'm concerned, is simply to > build that functionality into the browser: > - It's simpler, since there's on interprocess communication required. > - It's more portable, for the same reason. > - It's easier to distribute, since you only need one executable. I personally like the idea of dillo in one piece. I think a lot of people who give it a try don't get dillo + dpid + the dpis talking to each other correctly, and then they don't want to waste their time fighting with a random unfamiliar computer program. (Semi-relevant: I'm trying softphone programs out now, and they all demand lots of everything, and I can't tell which ones are worth how much trouble.)

April 9, 2011

Question about local file browsing

by obeythepenguin＠gmail.com

On Thu, 07 Apr 2011 03:53:01 -0400, Diego . <darkspirit5000(a)gmail.com> wrote: > I will try to explain some reasons > > 1 DPI system avoid duplicate code and complex share and sync code. > 2 It is a universal solution. It can be used for file, cookies, etc. > 3 Each new open dillo have access to previous running DPIs. > 4 Isolates DPIs and dillos each in a process. > > I think DPI system could be better too. It is not a fully stabilised > API too. And there is no docs or SDK to write DPIs > > More in detail: > 1.a: > With built-in local file browsing each dillo running have the code for > it. The most of the time that code is not used an each dillo waste > that mem. > With DPIs it is only loaded when needed and unloaded if not. > In the file case the DPI is a high performance solution (threads) that > in dillo can be a waste of mem, but not in an external DPI (you can > write and use other file DPI focused for mem saving) A couple extra kilobytes for file browsing is not wasteful, IMHO. If space is that tight, like in an embedded device, it could easily be #define'd out and added as a ./configure option, like with cookies. As I understand it, most of the memory used by local file browsing is dynamically allocated, anyway; it's not like those DilloDirs stay in memory for all eternity. There's a LOT of duplicate code in DPI -- it's just *different* duplicate code. For example, each one has to implement signal handling, authentication, etc., not to mention the mess of interprocess communication. There's also the added overhead of each separate DPI process, and the DPI daemon itself. > 1.b: > With the cookies the DPI system avoid code in dillo to share write in > the cookies file. It makes easy to debug cookies (an other paralles > code) with varios dillos. This is the example everyone uses to point out DPI's "strengths". Well, I've looked at the cookies code, and I'm going to call bullshit. 1) The cookies file is only accessed twice: to read cookies when the browser opens, and to write them when it closes. It doesn't need to be open at any other time. 2) As I understand the code, if multiple Dillo instances are running, all but the first won't have cookies anyway. 3) Here's the real kicker: *you don't need the cookies file*. Here's the code to prove it: http://dillo-win32.sourceforge.net/files/23-dillo-r1803.cookies.diff This is a long patch, but basically it removes the cookies DPI; integrates the code into the browser (fairly straightforward, because src/cookies.c already duplicates large chunks of the DPI verbatim -- what's this about redundant code, again?); and changes it to not read/write cookies from/to disk. That last part is trivial: just initialize the cookies file pointer to NULL, check for a file pointer before any read/write operations, and don't abort if there is no file pointer in a_Cookies_init. Dillo holds cookies in memory while running anyway, so again, *it doesn't need a cookies file* except for persistence between sessions. By the way, holding cookies in memory has several advantages. For one thing, it's a better balance between functionality and privacy, because you can access cookie-dependent sites without leaving traces on your disk. For another, if you have multiple Dillo instances running, the "redundancy" (read: isolation) can be a good thing. I often have two separate instances running, one for each of my Gmail accounts. Speaking of which, I've also moved HTTPS in-browser. Rather than re-implementing the HTTP engine as the DPI seems to do, I simply added transparent SSL support to dSock, my Winsock/BSD sockets portability wrapper. It required some nastiness to support the HTTP CONNECT command for proxying, since that has to be sent in plain text, but otherwise it needed only minimal patching; once you tell dSock to go secure, it will automatically call the SSL-enabled read/write functions for you. Here's the patch for that: http://dillo-win32.sourceforge.net/files/22-dillo-r1803.https.3.diff > 2: > With DPI system you dont need to do one thing for protocols, other for > downloads, other for cookies, etc. Each thing is a diferent problem, > but is handled in a similar way. src/capi.c, src/cookies.c, and various other source files beg to differ; those two in particular are very poor examples, since they're called from separate source files, under completely different circumstances, in completely different ways. In other words, you do one thing for protocols, ... I vaguely recall that my built-in downloader took only one function call to start, as opposed to at least three for the DPI (it cleans itself up automatically). It also has no external dependency on wget, or any interprocess communication for that matter. > 3: > All different process dillos (dillos running in different process) > have the same access to data an code of DPIs. Is it easy to share DPIs > processed data and functions of DPIs. > What dillo run a external program or what dillo process have the data > never mind if it is done with a DPI. What part of the DPI code do you consider "easy"? Interprocess communication is messy enough as it is, let alone the way DPI implements it. > 4: > If a process crash the other DPIs and the other dillo process continue > running. If it is a DPI it is re-run and the work continues (there is > a bug in the code: sometimes a defunct DPI can block a dillo) If a process is properly coded, it should never crash in the first place. I'm just saying. > About DPI system faults: > - Documentation > - Changing API and protocol > - Do not work on windows > - Try to simplify protocol, API and code > > There is a lot to talk to do better DPI system. Maybe you and me can > try to have DPI running in windows. I've considered porting DPI. The problem is, interprocess communication is completely different on Windows, and the best case scenario is that porting it would require a complete API overhaul. (Though I understand the API changes in every release anyway, so I suppose that isn't much of a problem.) A much more practical solution, as far as I'm concerned, is simply to build that functionality into the browser: - It's simpler, since there's on interprocess communication required. - It's more portable, for the same reason. - It's easier to distribute, since you only need one executable. I'm especially insistent on the last point. With all dependencies statically linked, I've got my port down to a single executable, and I hope to keep it that way. Up until the last release, you could fit the entire browser on a floppy disk -- and it's only bigger now because of OpenSSL, not because of anything in Dillo itself. (I've looked at the embedded libraries like yaSSL, which are much smaller, but I can't find a reliable download link.) Anyway, that's my two cents. ~Benjamin

April 7, 2011

Question about local file browsing

by darkspirit5000＠gmail.com

I will try to explain some reasons 1 DPI system avoid duplicate code and complex share and sync code. 2 It is a universal solution. It can be used for file, cookies, etc. 3 Each new open dillo have access to previous running DPIs. 4 Isolates DPIs and dillos each in a process. I think DPI system could be better too. It is not a fully stabilised API too. And there is no docs or SDK to write DPIs More in detail: 1.a: With built-in local file browsing each dillo running have the code for it. The most of the time that code is not used an each dillo waste that mem. With DPIs it is only loaded when needed and unloaded if not. In the file case the DPI is a high performance solution (threads) that in dillo can be a waste of mem, but not in an external DPI (you can write and use other file DPI focused for mem saving) 1.b: With the cookies the DPI system avoid code in dillo to share write in the cookies file. It makes easy to debug cookies (an other paralles code) with varios dillos. 2: With DPI system you dont need to do one thing for protocols, other for downloads, other for cookies, etc. Each thing is a diferent problem, but is handled in a similar way. 3: All different process dillos (dillos running in different process) have the same access to data an code of DPIs. Is it easy to share DPIs processed data and functions of DPIs. What dillo run a external program or what dillo process have the data never mind if it is done with a DPI. 4: If a process crash the other DPIs and the other dillo process continue running. If it is a DPI it is re-run and the work continues (there is a bug in the code: sometimes a defunct DPI can block a dillo) About DPI system faults: - Documentation - Changing API and protocol - Do not work on windows - Try to simplify protocol, API and code There is a lot to talk to do better DPI system. Maybe you and me can try to have DPI running in windows. Diego. 2011/4/7, Benjamin Johnson <obeythepenguin(a)gmail.com>: > I'm sure this has been asked before, but why on earth is something so > basic as local file browsing implemented through the (ludicrously > complicated, IMHO) DPI system rather than built in to the program? > > ~Benjamin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 7, 2011

Question about local file browsing

by obeythepenguin＠gmail.com

I'm sure this has been asked before, but why on earth is something so basic as local file browsing implemented through the (ludicrously complicated, IMHO) DPI system rather than built in to the program? ~Benjamin

April 7, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

Jeremy Henty wrote: > Jeremy Henty wrote: > > > > corvid wrote: > > > > > Probably reads the 0.1 as 0 and does the same bad thing we usually > > > get when we have 0 and don't have a URL argument sending us > > > somewhere else... > > > > So the bug is that Html_tag_open_meta() does not check that it has > > found a URL before doing the redirect? Does the attached patch look > > sensible? (The patch is a little messy, but all it does is wrap the > > redirect code in a "if (*content) { ... }".) > > Bump. > > Is this patch OK? OK, seeing as the patch is so simple and no-one has objected I have crossed my fingers and pushed it. Regards, Jeremy Henty

March 31, 2011

Re: Dillo-dev Digest, Vol 67, Issue 20

by jcid＠dillo.org

On Tue, Mar 29, 2011 at 01:21:48AM +1100, Purgatori Sakkara wrote: > > I hope that I am not sending this to the wrong place or anything, but I > just wanted to express my sincere gratitude to all the people working on > this, the great browser around :) Thanks a lot for your words! @devs: you may also read: http://gopherproxy.org/sdf.org/0/users/mrgnash/phlog/15-03-2011.txt (by the same poster) -- Cheers Jorge.-

March 28, 2011

Re: Dillo-dev Digest, Vol 67, Issue 20

by mrgnash＠sdf.lonestar.org

I hope that I am not sending this to the wrong place or anything, but I just wanted to express my sincere gratitude to all the people working on this, the great browser around :)

March 28, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Sun, Mar 27, 2011 at 03:56:27PM +0100, Jeremy Henty wrote: > Johannes Hofmann wrote: > > > Just for the record, normally it's better to make general changes > > and bugfixes to the main branch and merge them into development > > branches. > > "main" being FLTK 2.0 and "development" being FLTK 1.3, is that right? right > > Who is responsible for merging changes into development? So far I > have been thinking only about the 2.0 branch and treating 1.3 as > someone else's problem. Is that fair or should I be checking that my > changes merge into the 1.3 bramnch too? No, that's fine. Merging into development branches should be done by the developer who feels responsible for that branch. Cheers, Johannes

March 27, 2011