April 2011 - Dillo-dev - lists.mailman3.com

HTML5

by mr_semantics＠hotmail.com

Hello all, Forgive me if this has been discussed before (I do not recall seeing it since I have been following the mailing list). ?I recently started experimenting with some HTML5 stuff on a page I maintain, and as expected, dillo indicated an error in the html source. ?You can see the page here: http://www3.sympatico.ca/rsquared/gdb/ The error is: "HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid)" Now this does not surprise me at all, as I presume dillo is not expecting the new doctype declaration. ?Anyway, I thought I might raise this issue, and see what sort of mind the devs have about implementing HTML5 in dillo. ?Of course, I realise you fellows are probably up to your ears in the FLTK 1.3 port, but I thought this might make for an interesting discussion, if nothing else. ?To start off, I suppose the danger in implementing any of the new html stuff is that it is not standardised at all yet. ?See here for more: http://en.wikipedia.org/wiki/HTML5#W3C_standardization_process I guess the worry is that it could possibly be a bit of a moving target. Rob

April 16, 2011

Large Panel

by mr_semantics＠hotmail.com

> Date: Sat, 16 Apr 2011 12:04:26 -0300 > From: jcid(a)dillo.org > To: dillo-dev(a)dillo.org > Subject: [Dillo-dev] Large Panel >? > Hi there, >? > Does anybody use "panel_size=large" in dillorc? >? > I'd like to remove the option in the 1.3 branch, and keep > tiny, small and medium.My apologies for sending that last email to your address, Jorge. ?I am part of another mailing list, where when I hit reply it goes to the list, instead of the sender. ?I should look into changing this somehow with my email, as this is not the first time I have made this mistake. ?Anyway, as to my thoughts on the large panel size... I had actually been using the default, and had completely forgotten that you could change this. ?Now that you brought it up, I think I will be using the "tiny" setting. ?Long story short, you would have no objection from me if you got rid of the large setting. Rob?

April 16, 2011

Large Panel

by jcid＠dillo.org

Hi there, Does anybody use "panel_size=large" in dillorc? I'd like to remove the option in the 1.3 branch, and keep tiny, small and medium. -- Cheers Jorge.-

April 16, 2011

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