January 2004 - Dillo-dev - lists.mailman3.com

Re: https dpi
by Jorge Arellano Cid 03 Feb '04

03 Feb '04

On Sat, 25 Oct 2003, Madis Janson wrote: > I read the https.c included in dillo/dpi and seams, that it just > gets url and and dumps html. Yes, it's basically a dpi filter plugin. > What about content-type, cookies and POST > requests? Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? > > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Unfortunatelly I don't have definitive answers for these questions. There's more than one way to do it and the choice somewhat depends on what the underlying purpose of the bigger picture is. For instance: distributed design vs monolithic, quick implementation vs a more flexible one, low library dependencies vs linking dillo to a bigger set. Personally, I think that patching dillo with an integrated quick implementation of https (like Indan's) while we develop a more flexible dpi that provides at least the same, can be a good approach. I'll try to briefly comment your concerns: > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Yes, that happens with dpi filters. The idea in this case is to have an http dpi that's able to handle several connections at the same time (like the downloads dpi). That is: a dpi server instead of a dpi filter. With that scheme session cache is easy to implement. (and BTW much easier for the developer because he can arrange things much more freely than when patching inside dillo). > content-type (as above). The https dpi would need to listen the HTTP stream and so has access to the content-type sent by the remote https server. > Cookies Cookies will end being a dpi! Currently dillo enables cookies for the first instance only (this is old problem of sharing a single resource among several clients). Fortunately dpi solves this, as with the current bookmarks dpi server that can be shared by multiple running instances of dillo. When this port is done, the one-instance-only restriction for cookies will be gone. > POST POST data can be passed to the https dpi using dpip. This information is inside the DilloUrl. > Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? Yes I agree with that reusing dillo's http may come handy. Now, dillo does http 1.0 only so having it done inside a dpi can also bring http 1.1 (as with wget and current https.c). The other interesting point is that the SSL/TLS library spec states that appart from making a socket secure, the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. So having a generic SSL/TLS gateway may look interesting but it can get tricky to implement. For intance: handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), are to be handled in different ways regarding what the protected protocol using SSL/TLS is, the transport circumstances and the user's choice. (ah, and all the alerts can have a "level" of fatal or not). With a gateway, having only the option of closing the connection is not enough. Question dialogs can be implemented in the gateway process itself though (a GUI inside the dpi), and you also have to take care of differentiating the protocols. With dpi, the questions and actions can be communicated to dillo with dpip or be made part of the dpi server. It provides more flexibility. Making SSL a part of IO, comes with the burden of having to develop all of this error handling knowledge inside the IO layer (making dillo grow in size and complexity). Including questions, actions a protocol differentiation. HTH Jorge.-

2 2

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3
by Jorge Arellano Cid 31 Jan '04

31 Jan '04

On Sat, 31 Jan 2004, Riccardo wrote: > > > > What could be the problem? > > > > A missing header! Fix is commited. > > Please test it and tell us how it works. > > > > -- > > To test, I had to use the CVS of course. I run autogen.sh and > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. > -DDPIDRC_SYS='"/usr/local/etc/dpidrc"' -I/usr/local/include > -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 > -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter > -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" \ > -c -o dpid.o `test -f 'dpid.c' || echo './'`dpid.c; \ > then mv ".deps/dpid.Tpo" ".deps/dpid.Po"; \ > else rm -f ".deps/dpid.Tpo"; exit 1; \ > fi > dpid.c: In function `handle_sigchld': > dpid.c:562: error: `WAIT_ANY' undeclared (first use in this function) > dpid.c:562: error: (Each undeclared identifier is reported only once > dpid.c:562: error: for each function it appears in.) > make[2]: *** [dpid.o] Error 1 Hmmm.... > Is there still something missing in cvs? WHy is it not there? Maybe > release me a new tarball so I can test it on both aix and sparc, or tell > me how to build cleanly from CVS. > Or WAIT_ANY is not declared on solaris? hmm :-) Some Solaris seem not to have it. :( I decided to replace WAIT_ANY with -1 as in dillo.c; commited. Please test it on aix and sparc. Use the Jan30 tarball and just replace WAIT_ANY with -1 in: dpi/downloads.c and dpid/dpid.c Cheers Jorge.- PS: there's no need to CC me. I'm on dillo-dev.

1 0

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3
by Jorge Arellano Cid 31 Jan '04

31 Jan '04

On Sat, 31 Jan 2004, Peter Sinn wrote: > > Hi, > > first let me say that I have been using Dillo on my Sun Ultra 10 for > quite some time now and like it very much! Thanks for the comment Peter! > Am 31. January 2004 12:14 Uhr schrieb Jorge Arellano Cid: > > > There's no PF_LOCAL in the CVS tarball. Please try it. > > > > (http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz) > > > > dillo 7.3 compiles without problems on my machine, therefore I have > just tried to compile the new version. But unfortunately, with > dillo-0.8.0-pre.Jan30 I get the following compile error (gcc version > 3.3.2, SPARC/Solaris 9): > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. > -DDPIDRC_SYS='"/usr/local/etc/dpidrc"' -I/usr/local/include > -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 > -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter > -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" \ > -c -o dpid.o `test -f 'dpid.c' || echo './'`dpid.c; \ > then mv -f ".deps/dpid.Tpo" ".deps/dpid.Po"; \ > else rm -f ".deps/dpid.Tpo"; exit 1; \ > fi > dpid.c: In function `handle_sigchld': > dpid.c:561: error: `WAIT_ANY' undeclared (first use in this function) > dpid.c:561: error: (Each undeclared identifier is reported only once > dpid.c:561: error: for each function it appears in.) > make[2]: *** [dpid.o] Error 1 > > > What could be the problem? A missing header! Fix is commited. Please test it and tell us how it works. -- Ah, I also fixed the handling of the <P> element for the bug-meter. It fixes the problem of wrong messages like this one: "HTML warning: line 200, unexpected closing tag: </p>. -- expected </ol>" (now this part should be release-ready) -- Thanks for the quick feedback Jorge.- PS: There's no need to CC me.

2 1

Re: [Dillo-dev] Automake and dynamic linking
by Jorge Arellano Cid 31 Jan '04

31 Jan '04

Jorgen, Andreas, Riccardo, Matti, Bob (portability issues here): Hi, here is a brief covering the latest portability patches now in CVS. These are not final an certainly need testing, so lets try to get it straight. Issues: libpng, pthreads, proper linking, AF_LOCAL, libc5, PS2 libpng: ------ On Wed, 14 Jan 2004, Jorgen Viksell wrote: > Hi! > > tis 2004-01-06 klockan 16.01 skrev Jorge Arellano Cid: > > [...] > > We can't rely on libpng-config because it would break support > > for older distros (for instance slackware 3.9), and there're > > plenty of dillo users with old distros on laptops. > > Fair enough. Using Debian unstable I tend to forget about those people > stuck with non-evolving distros. > > > The current png detection routine has come a long way to be > > able to detect the library on a wide range of SW/HW combinations. > > Maybe the best approach is to try libpng-config first, and when > > not present, try the older libs. > > I made it do so. Could you please try out the fallback code, using: > PNG_CONFIG=foobar ./configure > And if it still fails could you send me the config.log file. Sorry for taking a long time to answer, I got a lot of troubles installing an old libc5 distro (Slackware 3.6) for testing. These were unrelated to the distro and not worth to detail here! ;) The simple fallback-test passed on my slk current, but the old installation payed off quickly, because it failed on it. For instance: <q> checking for libpng-config... missing checking png.h usability... yes checking png.h presence... yes checking for png.h... yes checking libpng/png.h usability... yes checking libpng/png.h presence... yes checking for libpng/png.h... yes checking for png_check_sig in -lpng... no configure: WARNING: *** No libpng found. Disabling PNG images *** </q> Fixed, added "-lm" and a "&& break" to avoid the second header test when the first is present. The version in CVS works both with the current and libc5 distros. As for the image disabling, although I don't see much use for it, I left to avoid some work at this stage. The one thing I don't like is the #ifdef stuff. Well, if it's not worth it can be removed. pthreads: -------- I added the "pthreads" (with an 's') to the search list as Andreas suggested. Riccardo: please test if this works for you. I made a tarball so you don't need to play with autoconf/automake/autogen. URL: http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz Note: there's still some work to do with this one, read below. proper linking: -------------- Now the linked libraries are ok (the problem was that dpis and dpid got all of the libraries used by dillo linked in). ...except for pthread that is till present on dpi, dpis. AF_LOCAL: -------- After studying the history of the socket library development and socket.h for linux, BSD, HURD, etc, it seems that all these are (should be) the same: PF_UNIX : old BSD name for PF_LOCAL PF_LOCAL : POSIX for AF_LOCAL PF_FILE : seldom used POSIX for AF_UNIX AF_LOCAL : somewhat old but the most compatible. AF_UNIX : oldest. Fixed this for the whole tarball. It works on both of my testing environments. Should work for everyone. libc5: ----- Now it compiles cleanly with libc5. Except for a warning on a repeated symbol between libjpeg and autoconf. --innocuous though PS2: --- > [Bob wrote] > - my experience of recent cvs, compiled on the playstion2, (blackrhino > 2.2.21 kernel), apparently shows a disconcerting feature. After a few > minutes of scrolling up and down standard web-sites the whole system > will hang (eg it's unpingable, and doesn't respond to any keyboard > input), and needs a hard reset :-( > > Anyone else currently testing on the ps2 please (and hopefully had > better experiences, or a fix)?? I don't have a PS2, but when testing on libc5, there was a similar problem (crash after scrolling, or crash instants after starting) when _some_ of the libraries used by the X server where compiled reentrant and some others not. In fact I was upgrading slk3.6's with the ones at: http://www.linuxsavvy.com/resources/ and some links pointed to the old ones. Most probably these problems stem from an static errno. Another source can be a non reentrant gethostbyname. If dillo-0.7.3 work right on it, I'm puzzled. That's it. This CVS should work on the same platforms than before and with a few more. Please test and report. Best Jorge.- PS: Those that have had problems with 0.7.3, please test this CVS version, or tarball: URL: http://www.dillo.org/test/dillo-0.8.0-pre.Jan30.tar.gz PS2: Ah there's also a fix to include "dpidc". It fixes "make dist".

3 2

Re: [Dillo-dev] building on AIX, gcc, dillo 0.7.3
by Riccardo Mottola 31 Jan '04

31 Jan '04

on 1/28/04 5:58 PM, Andreas Schweitzer at Andreas.Schweitzer(a)hs.uni-hamburg.de wrote: >>> >>> and there I just found : >>> >>> http://aixpdslib.seas.ucla.edu/packages/gtk+.html >> Unfortunately, aix 4.2 is quite out of date (but my original rs/6000 is >> beginning to show its age too). > > I just checked. Back then on that machine I had/have : > > $ lslpp -l | egrep -i gtk > freeware.gtk+.rte 1.2.8.0 COMMITTED Gimp ToolKit GUI Library > freeware.gtk+.rte 1.2.8.0 COMMITTED Gimp ToolKit GUI Library > > So, I took it from one of these sites :-) > > Anyways, my hunch yesterday was right when I suspected a small patch > for AIX. I have a diff for AIX lying around which is attached. > The fix produced a result: in fact build stops this way now: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/includ e/gtk-1.2 -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -g -O2 -D_ REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -c `test -f 'dpi.c' || echo '. /'`dpi.c dpi.c: In function `Dpi_get_server_uds_name': dpi.c:497: `PF_LOCAL' undeclared (first use in this function) dpi.c:497: (Each undeclared identifier is reported only once dpi.c:497: for each function it appears in.) dpi.c: In function `a_Dpi_bye_dpid': dpi.c:749: `PF_LOCAL' undeclared (first use in this function) gmake[1]: *** [dpi.o] Error 1

2 1

ASK FOR HELP:"view source" and edit data to send.
by FUN TOES 30 Jan '04

30 Jan '04

Some websites can't be visited by dillo.So I think of writing a patch to view the raw data(including header) from the server and send the raw data modified manually to the server. It is very easy to edit the data to send by modifying the function Http_send_query().But I do not know how to get the raw http data from the server.What is the function that I need read deeply? And I do not think IO_read()is a good selection.The function send raw data to html parse maybe a good selection.But I am a newbie,and I have difficuty in finding the correct function. Would you like help me find it?Appreciation for your help. -- ___________________________________________________ Check out the latest SMS services @ http://www.operamail.com, which allows you to send SMS through your mailbox. Powered by Outblaze

2 1

building on AIX, gcc, dillo 0.7.3
by Riccardo 27 Jan '04

27 Jan '04

Hwllo, I sent a private message, of which a reply was CC to this list AFAIK, about building dillo on my AIX system. The problem are threads. Pth can't be used and so I need the system's native threads. A solution was offered me but another email asked for more information, so I report first this information here before trying blindly. configure reports: checking target system type... rs6000-ibm-aix4.2.1.0 as far the system concerns. The error during configure is: checking whether threads work with -pthread... no. Now we will try some libraries. checking for library containing pthread_create... no configure: WARNING: *** No pthreads found. *** gcc -v yields: Reading specs from /usr/local/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.95.3/specs gcc version 2.95.3 20010315 (release) while lslpp -l | egrep -i 'thread|xlc|gcc' bos.rte.libpthreads 4.2.1.0 COMMITTED pthreads Library xlC.cpp 3.1.4.0 COMMITTED C for AIX Preprocessor xlC.rte 3.1.4.0 COMMITTED C Set ++ for AIX Application greets, Ric

3 3

[Dillo-dev]Buggy HTML, the new parser and webmasters
by Andreas Schweitzer 27 Jan '04

27 Jan '04

Hi all, First : my apologees for a rather large mail ! Now, that the bug counter is in dillo, and with Madis' last post, it's a good coincidence that I just tried to convince webmasters of 3 sites I usually visit to fix their HTML. From 2 I haven't heard a thing (and they are not even THAT huge), but from www.osnews.com I got a reply very fast - and it turned out to be an extremely interesting conversation. I asked her for permission to forward it to the list, and here it goes. I sorted it chronolically, with some comments of mine in between. I omitted my first mail - it was just the HTML warnings of the new parser along with a kind request to fix the page. WARNING, BIG REMINDER : Don't flame her - it's not about this individual site, it's about general practice and the general attitude towards standards ... After all, the e-mail conversation started in privat and she didn't have in mind that a lot of people would read it. And I think she deserves credit for taking her time and lay out her arguments and explaining everything in a very friendly manner. On Sat, Jan 24, 2004 at 06:36:27PM -0800, Eugenia Loli-Queru wrote: > Hello Andreas, > thanks for the heads up. > I looked at the error messages, and I know what is wrong. Please note that > all forms and tables ARE closing in the code, it is just that your parser is > not realizing it. > You see, I start the form inside a table's cell, but I close the form > outside the table. This is not 100% valid code, but it is like that for a > reason. This is causing your parser to spit all these errors (all the errors > below the form error are just a side effect of the first error). > So, the reason I close the form outside that table is because I am trying to > go around bugs on Netscape 4 and IE. As you can see, the cell that holds the > form has a black background color. If I close the form inside that cell, IE > and NS4 create a new paragraph inside that cell, even if my code never asked > for it. And that looks ugly. Up to here, you could argue a lot about how to design a web page, to not wanting to dictate how the page looks and leave it to the browser, to us CSS and whatnot. With enough arguing one could even convince this very author to change (not likely though, see below). BUT : the interesting part comes now : > So, the "trick" that many web developers of my time use a lot (see: > hand-written HTML), is to close the </FORM> outside of tables or places > where it screws up the design. It is a well-known trick, and so your new > parser is going to meet it a number of times in the future. I suggest you The above is frightening .... > fix your parser to understand "non-normal" code like that, and realize that > the form does close as expected. Of course, for us that's not fixing but breaking ;-) .... Here is now my reply (rather long, and you will know the arguments if you follow the lamiling list) : > Hi Eugenia, > > Thanks for the reply and explanation. > First of all : I am not a core developer of that browser - just > a steady user and occasional contributor. > > However, if this mail came from one of the developers or if I told > them to follow your advice, you would either be ignored or flamed ;-) ... > I will try to do neither. So please do keep in mind that my response > is meant as a friendly food for thought or possibly some constructive > criticism. > > Discussions about fixing broken HTML do come up on the mailing list > from time to time. And the consent is to just not do it - for a number > of reasons (I probably will forget some). > - what good are standards if nobody conforms to them, and instead an > own (not very strict !) psuedo-standard develops ? > - It's not a browser's job to guess what the author wanted to have displayed. > - It costs man-power and CPU cycles to detect and fix broken HTML. > We prefer to spend the man-power on developing something useful instead > of broekn HTML-detection code. And we prefer to give the CPU cycles > to the user (BTW, dillo is the snappiest grafic browser I know - maybe Links2) > > All right, but we already detect the problem of your page, you may say :-) .. > and indeed, the *old* parser was closing out of order. In fact, I could > configure dillo to still use the old parser and your page will look great. > BUT : then other pages break :-( - they have buggy HTML, too. And there, > closing tags with the new method is better then with the old method. > So, in chosing which parser to use, the default is the standards complying > method of interpreting HTML (also, the old parser was buggy and not quite > right). Oh - and if we care about the web sites we also tell/told the > authors if these other pages that they have buggy code ! > Now, why then are Mozilla or the other browsers displaying all correctly ? > Probably because they did spend man-power and CPU-cycles to guess what the > author wanted. > I had to smile when you wrote, "Fix your parser to understand non-normal HTML", > because I thought, "That's not fixing it, that's breaking it". > > When I design web pages, I usually make them pass (if possible) > validator.w3.org and if they look ugly in ancient - and buggy ! - browsers, > bad luck ! I realize, my pages are nothing professional like your site, > but still, is it worth to support buggy broswers ? How many visitors > are actually using Netscape 4 ? Probably more than dillo, but the comparison > should be non-buggy vs. buggy browsers. About IE - are all versions > of IE bahving like this ? Then my argument would be, why support MS's > interpretation of standards ? (and outside of HTML you probably will > agrre ;-) ... after all, don't we all know lots of alternatives and fight > for them ?) You as a professional web site probably do have to support > buggy broswers, but the question still may be asked. > > Finally, some links to archived previous discussions : > http://news.gmane.org/group/gmane.comp.web.dillo.devel/thread=1324/force_lo… > (if you don't want to read all of it, read at least Eric Gaudet's posts) > And here is the explanation of the new parser : > http://article.gmane.org/gmane.comp.web.dillo.devel/1434 > > By now, you know that the other problematic site was slashdot ;-) ... > (among others !) which displays ok with the current parser - but also is > buggy HTML - and they know it ! > > And before I forget : Yes, I saw a lot of pages that look quite ugly > with the strict interpretation. And I also only tell the webmasters > of pages for which I care :-) > > And as a really last word : the new parser may indeed have room for > improvement, and some more closing may indeed be possible as a compromise, > BUT, as I said, I'm not a core developer. > > As I said in the beginning, this was meant as food for thought, not flaming. > If you should decide to change HTML after all, that would be fantastic. If > not, hopefully I at least did explain myself well. > > Cheers > Andreas And here is her 2nd answer: > Thank you for the email Andreas, > however, I must say that the code in that form won't change. IE has more > than 70,000 viewers daily on osnews, and Dillo has about 20. So, as you can > understand, being compatible with the broken IE is more important to us, > even if that means that we have to not be validated. In fact, not being > validated, it is a given for big sites, because in order to give a > specific/certain look, you have to do tricks like the one I described to you > in order to render the same on all big browsers. Now you could, of course, go and say "screw this site" .... but the following is at least ineresting food for thought. I don't fully agree, but I can understand the point of view. > Also, please put in mind: my husband is in the browser business. He is a web > browser developer for OpenWave.com among his team. They don't have the > specific problem of out-of-order-tag-closing because they know that many > sites are like that, so they have to go around this problem, OR they won't > be able to sell their browser to anyone. > > This is a market. Even for the free Dillo. Dillo's job is not create the > most "correct" parser in the world, but to render most sites in the world. > If the first was true, then Dillo is nothing but an "Amaya", a test, a proof > of concept. But if the second is true, then Dillo is really a usable by > people browser. > > So, depends what its developers want. If they want a proof of concept, no > problem with me, osnews and most other sites won't work. If they want a > browser that works for most people, they need to sit down and go around > buggy HTML (created by either amateur developers or from developers that > they had to go around bugs). For example, IE even goes around this bug <a/> > and understands that the developer wanted to write </a> instead. Big > browsers do such error checking and go around buggy HTML, because it is the > only way they can be widely used. In my case of course, it was me that I had > to go around their bugs. > > So, it all depends what the Dillo people want. It is not what I, or you, > want, but what their real targets are: proof of concept project or a real > USABLE browser. > > If that was me, it would have being the second. And it ain't my fault that > IE has these bugs that I have to go around, it is my job to make sure my > page renders well for most of my readers. :) > > Rgds, > Eugenia > > --- > Editor in Chief > http://www.OSNews.com When I asked her for permission to forward her mails to the list she added another intersting quote : On Sun, Jan 25, 2004 at 08:53:17PM -0800, Eugenia Loli-Queru wrote: > You can go ahead and quote some of the stuff I said. > BTW, I discussed the matter with my husband (who as I said is in the browser > business) and he told me: > > "Creating an HTML browser and a Web browser are two different things. The > first one just needs to do the job right and parse HTML correctly, the other > one just has to be able to render web pages in any possible mean. These are > two different beasts and targets --unfortunately." > > I am afraid this is the reality of any product though, not just browsers... > Reality market... :( > > Eugenia > Bottom line : it may be possible to convince individual sites to fix their HTML, but what about really big sites that use these ... err ... "workarounds" ? Do they really care how a little browser interprets their HTML ? They care if HTML looks good in IE - reality sucks. It's extremely frustrating. And even more so, when I have to look at garbeled pages ;-) .... The situation may improve over time when more and more sites use CSS and don't have to rely on such dirty formating tricks - but then again, how many bugs has IE there, that authors want/will work around ? And to repeat my reminder : Don't flame her - it's not about this individual site, it's about general practice and the general attitude towards standards ... And again I think she deserves credit for taking her time and lay out her arguments and explaining everything in a very friendly manner. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

3 2

worried about dillo (cathedral and bazaar)
by linux seaq 27 Jan '04

27 Jan '04

Hi, i want to express my gratitude with the dillo developers, this is a really nice product, i use it everyday. I use mozilla only for banking, hotmail and flash sites. I'm only a user i'm not a developer, so my point of view is mainly from an user's perspective. Since dillo's win32 fork and previous discussion, it was clear to me that dillo development was, in some way, closed. That odd feeling was confirmed by the "memo" sent by main developers about patches and additions to dillo. Since that mail, all the "foreign" contributors stopped to share their improvements to dillo project.Or it seems to me at this time (PLEASE PROVE ME WRONG) That's really sad 'cause what i'm seeing right now is some kind of slowness on the development of dillo, and somehow is getting behind in needed functionality (frames,https,downloads,images, a lot of stuff out there). - from an user point of view - I recently re-read the cathedral and bazar paper, and thought to my self that dillo was heading in another direction. It seems to me that there's no intention to receive help from others, or get into account other's contributions. I believed that the main force behind a project weren't its main developers but its users and contributors. That mix made projects grow and grow. And dillo rejected that "magical" force. I'm just writing these thoughts, because as i said, i'm worried about dillo. I can't even imagine how painful would be to surf the web without it. Please everyone who loves dillo, do something so this nice project can grow without restrictions. Please don't get me wrong i don't want to start a trial, i just want dillo to evolve and get better everyday, with everyone help. Regards, Andres

3 2

small politically incorrect html parser patch
by Madis Janson 27 Jan '04

27 Jan '04

when you want to use dillo for browsing instead of html test tool, then this little patch is useful for many stupid webs, which randomly close or not close font tags whenever happens and whereever happens... diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in dillo-tab/src/html.c dillo/src/html.c --- dillo-tab/src/html.c 2004-01-25 04:37:21.000000000 +0200 +++ dillo/src/html.c 2004-01-27 04:27:18.000000000 +0200 @@ -4280,7 +4372,7 @@ static const TagInfo Tags[] = { {"dt", 'O', Html_tag_open_dt, Html_tag_close_par}, {"em", 'R', Html_tag_open_em, Html_tag_close_default}, /* fieldset */ - {"font", 'R', Html_tag_open_font, Html_tag_close_default}, + {"font", 'O', Html_tag_open_font, Html_tag_close_default}, {"form", 'R', Html_tag_open_form, Html_tag_close_form}, {"frame", 'F', Html_tag_open_frame, Html_tag_close_nop}, {"frameset", 'R', Html_tag_open_frameset, Html_tag_close_default}, It makes a bit less likely, that the font tags screw up every other one (like tables and forms)...

1 1