- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Problems with gziped content encodings pages and proposal

by Diego Sáenz

Hello again. I have started to code my proposal. I have a little patch with the easiest part (dillo protocol part) so people can test it if they want. The patch is highly experimental. Dpid is not modified so (until it(the most complex part)) DPI tree and names of protocols DPIs will be break. It can be solved with a few moves and renames, but do not try it in a non test system if you do not known what are you doing. The patch works with current cvs. After compiling a dillo with the experimental protocol patch when dillo finds a url that do not start with http: or about: it will ask to dpid for a service called protocol_PROTOCOL-PART-OF-URL (examples: protocol_ftp for ftp urls, protocol_data for data urls , protocol_javascript for javascript urls(if you delete the code in html.c that intercepts javascript), ...). I will use protocol_https for examples from now. How dpid is not changed it will exec ~/.dillo/dpi/protocol_https/protocol_https.dpi or $dpi_lib/dpi/protocol_https/protocol_https.dpi (in the case that the file was there when dpid started) The changed dpid will exec the user selected DPI for that service when done. Until that If anybody want to play with this code apply the patch, compile with care(do not install it for example), create a DPI(a filter script one for example) in .../dpi/protocol_YOUR-PREFERED-PROTOCOL/protocol_YOUR-PREFERED-PROTOCOL.filter.dpi , stop and restart dpid and test pointing compiled dillo to YOUR-PREFERED-PROTOCOL:WHATEVER-YOU-WANT I have make a script for javascript urls to test it(see upper comment). I will try to code a more complex part (mime) now. Diego.

Aug. 25, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Diego Sáenz

El Thu, 24 Aug 2006 17:07:21 +0000 (UTC) Sam Trenholme <sam+dillo(a)chaosring.org> escribio: [...] > I would look at the "i18n" version and try and add Javascript support > to it (or, better yet, EMCAscript support). Personally, I think Dillo > needs some level of Javascript support; a lot of high-profile sites > (can we say MySpace and their crappy JavaScript and HTML) plain simply > do not work without Javascript. If you do it, i will try to make a Dillo Plug-In with it. A DPI will work unmodified with or without i18n-patch/fork. If you want any help about Dillo PlugIns ask in the list and i will try to help. > I also believe that Dillo shouldn't try to get CSS support; the last > thing I want is yet another browser with buggy CSS that I have to > design around. If Dillo is going to support CSS, I don't think the > support should become a part of a stable release of Dillo until Dillo > can render ACID2 perfectly. A site that uses CSS is perfectly usable, > albeit a bit ugly, in a browser that doesn't have CSS. I disagree with you. Dillo needs CSS, well better said i need a dillo with CSS :P and i think that a lot of persons need it too. Until dillo suport enought the standard and pass ACID2 a note "wait until CSS test passed before mail your webmaster or test a page with dillo(if you are a webmaster)" can be enought. Dillo is still beta. Diego.

Aug. 25, 2006

Re: [Dillo-dev] The kind of computer that is perfect for Dillo

by Hans Hohenfeld

On Thu, Aug 24, 2006 at 05:07:21PM +0000, Sam Trenholme wrote: > This is the kind of computer that is perfect for Dillo: > > http://linuxdevices.com/news/NS6828123924.html > > Summary: About $100, P166, 128 megs of memory, roughly the size of a > VHS videocasette. > > This is the perfect computer for Dillo--128 megs of ram really isn't > enough memory to run Firefox well, and Firefox's rendering will be > quite slow on a P166, especially on big pages. I have a laptop with Pentium M 266 MHz and 96 MB RAM. I'm using Firefox and Dillo on that machine, while Firefox is most times much to slow (and slows down the rest of the system). > > That said, I feel there are some issues that stop Dillo from being the > browser to use on such a machine. > I agree, that's why I still use firefox on my laptop (which is a pain) > Now, before giving out my "shoulds", I understand what it takes to > make code happen in the open source world: The submission of money > or patches. I have my own little open-source project, and I do > let out a sigh whenever someone says "Your program should be able to > do XXX". I do listen to these requests, but it sometimes takes years > for those requests to become real code. > > So, I hope people on this list will humour me and let me share > my thoughts about Dillo. > > The problem is that Dillo doesn't support a lot of high-profile > internet sites right now. > > OK, you say, so submit a patch and help with Dillo development. > > Well, the problem is that I don't think such a patch will be > accepted by the Dillo developers. > > People, of course, know about the patches over at > http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n > > This patched version of Dillo (or should I say, this fork of Dillo) > also supports tabs, frames, UTF-8, and even has buggy support for real > HTML redirects. > > I was able to read and send webmail both with Yahoo and Gmail using > the "i18n" version of Dillo. I can't say the same for the last stock > version of Dillo I tried; I understand that the "i18n" changes may > make the code more messy. I think we're looking at different > philosophies here, and I think we may hit the point of having a > true fork should these enhancments continue to not be merged in to > the main Dillo source. > > If I were to take some time out from my own project on work on > Dillo, I would not work on the main version--I would work on > the "i18n" version, since it is usable with a number of sites that > the mainline Dillo can not access. > > I would look at the "i18n" version and try and add Javascript support > to it (or, better yet, EMCAscript support). Personally, I think Dillo > needs some level of Javascript support; a lot of high-profile sites > (can we say MySpace and their crappy JavaScript and HTML) plain simply > do not work without Javascript. I remember a discussion on this list about this patched Dillo version (or Fork). I think the main reason against it was, that the code is to much messed up and doesn't fit dillo programming guidlines (Naming Conventions and so on), but maybe I remember wrong. > > I also believe that Dillo shouldn't try to get CSS support; the last > thing I want is yet another browser with buggy CSS that I have to > design around. If Dillo is going to support CSS, I don't think the > support should become a part of a stable release of Dillo until Dillo > can render ACID2 perfectly. A site that uses CSS is perfectly usable, > albeit a bit ugly, in a browser that doesn't have CSS. > I definitely disagree. From my point of view, CSS is the most missing feature in Dillo. Frames are minor impotant (as only bad websites use them), Javascript is very much necessary, but CSS seems to be the most important feature Dillo needs. Some basic CSS attributes like colors, positioning would be a good start. I agree, that it is very important to implement CSS support as close to the standard as possible. > Anyway, these are just my 2 millicents. I understand that it takes > either real code or real money to make these changes real, and since > I'm currently offering neither, feel free to cheerfully ignore my thoughts > or to flame me to a crisp. :) > - Sam > -- derhans > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 24, 2006

The kind of computer that is perfect for Dillo

by Sam Trenholme

This is the kind of computer that is perfect for Dillo: http://linuxdevices.com/news/NS6828123924.html Summary: About $100, P166, 128 megs of memory, roughly the size of a VHS videocasette. This is the perfect computer for Dillo--128 megs of ram really isn't enough memory to run Firefox well, and Firefox's rendering will be quite slow on a P166, especially on big pages. That said, I feel there are some issues that stop Dillo from being the browser to use on such a machine. Now, before giving out my "shoulds", I understand what it takes to make code happen in the open source world: The submission of money or patches. I have my own little open-source project, and I do let out a sigh whenever someone says "Your program should be able to do XXX". I do listen to these requests, but it sometimes takes years for those requests to become real code. So, I hope people on this list will humour me and let me share my thoughts about Dillo. The problem is that Dillo doesn't support a lot of high-profile internet sites right now. OK, you say, so submit a patch and help with Dillo development. Well, the problem is that I don't think such a patch will be accepted by the Dillo developers. People, of course, know about the patches over at http://teki.jpn.ph/pc/software/index-e.shtml#dillo-i18n This patched version of Dillo (or should I say, this fork of Dillo) also supports tabs, frames, UTF-8, and even has buggy support for real HTML redirects. I was able to read and send webmail both with Yahoo and Gmail using the "i18n" version of Dillo. I can't say the same for the last stock version of Dillo I tried; I understand that the "i18n" changes may make the code more messy. I think we're looking at different philosophies here, and I think we may hit the point of having a true fork should these enhancments continue to not be merged in to the main Dillo source. If I were to take some time out from my own project on work on Dillo, I would not work on the main version--I would work on the "i18n" version, since it is usable with a number of sites that the mainline Dillo can not access. I would look at the "i18n" version and try and add Javascript support to it (or, better yet, EMCAscript support). Personally, I think Dillo needs some level of Javascript support; a lot of high-profile sites (can we say MySpace and their crappy JavaScript and HTML) plain simply do not work without Javascript. I also believe that Dillo shouldn't try to get CSS support; the last thing I want is yet another browser with buggy CSS that I have to design around. If Dillo is going to support CSS, I don't think the support should become a part of a stable release of Dillo until Dillo can render ACID2 perfectly. A site that uses CSS is perfectly usable, albeit a bit ugly, in a browser that doesn't have CSS. Anyway, these are just my 2 millicents. I understand that it takes either real code or real money to make these changes real, and since I'm currently offering neither, feel free to cheerfully ignore my thoughts or to flame me to a crisp. :) - Sam

Aug. 24, 2006

Problems with gziped content encodings pages and proposal

by Diego Sáenz

Hello. I am a daily user of dillo and i am finding problems with pages served with content-encoding = gzip and dillo mime detection code. For example when i try to open en.wikipedia.org or es.wikipedia.org dillo says "HTTP warning: Content-Type 'text/html; charset=utf-8' doesn't match the real data" When download with wget y see that the problem is that the page is gziped so i think that now wikipedia sends pages with conten-encoding: gzip. Proposal I have a proposal to use DPIs to manage protocols, mime, encodings and maybe scripts whitout modifing dillo source code each time that a dpi is added. Before in the list i have defended to have mime, protocols and script DPIs that call the right DPI for each task when dillo ask for a unknown mime type, protocol or script but this do not fit very well with the DPI infrastructure and need more DPI process runing and that it is better to avoid. Sorry, i think that it was the better option. I think that the way to fit mime handling with DPIs is to use the documented (but not fully implemented) concept of DPI service. In DPIs docs dillo do not call directly a DPI it ask dpid for a service and dpid returns a DPI. In this way various DPIs can be installed for a given service and the user can use whatever he what. In fact in the code dillo ask dpid for a service, but dpid can not handle more than a DPI for a given service(it do extrange things). Basic idea: When dillo do not known how to access to a url like mms:/something or show a mime type like image/xpm it can ask for a protocol_mms service or mime_image%2Fxpm service. We can fix dpid too. It will only need a configuration file to store user preferences for each service. Details Protocol DPIs can translate the unknown protocol to http (like https, ftp and data DPIs) or show a html page with actions about the protocol. For example a mms DPI can show a page with options to hear the mms stream(with mplayer) or download it (with mimms). An extension to the download_gui DPI to support downloading unknown protocols can be usefull. When download is not one supported by wget it can send open_url to dillo or ask dpid ... Mime types need a mime_x-dillo%2Fx-unknown because a file can be send without content-type and dillo can fail to discover the mime. A DPI handling it can use 'file --mime ' and resend the file to dillo with correct mime. A way to not resend the file will be better, maybe dillo can cache it if the file is small and is not a local file. If it is local it can send the url or path. A dpid more flexible configuration is needed so users can use the 'file --mime' DPI with occet/stream if they want. Using a path to the DPI with base at ~/.dillo/dpi or the dpi_lib in dpidrc can be sufficient. Surely a fallback DPI can be usefull. If dpid can not return a DPI because there is not service for that mime dillo can ask for a mime_x-dillo%2Fx-service-not-found or mime_x-dillo%2Fx-fallback that DPI can show an error or list DPIs to download and install or show a search engine For security reasons a mime_... and inlined_mime_... groups of services can be needed so an image or an object tag data automatically loaded from a page to show can be diferent from user clicked ones. Content encoding can use a group of encoded_... service names. (content_gzip for example) This do not need to detect the encoding because if there is not content-encode it is not encoded. Fallback can be needed. Scripts need more thought but if dillo send scripts tags to script_aplication%2Fjavascript and implement html intrinsic events a DPI can start to do easy things as redirect, status line scrolls(sigh) or javascript based links. (javascript based links can be done with a protocol_javascript easely) I mail this because i want coments and help. If you has read this boring (and bad writed) text until here, please do not think on comments or help, Just do if! :) Diego. PS: I have a debt of a parser code to dillo. It only need a clean up but is finished and have less size that the old glib parser code. :P

Aug. 24, 2006

printing from dillo

by Globe Trotter

is it possible to print a webpage from dillo? many thanks and best wishes! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

July 13, 2006

Re: [Dillo-dev] Re: how do i unsubscribe?

by Patrick Shanahan

* Andrew A. Gill <superluser(a)frontiernet.net> [07-03-06 19:34]: > Yes, I know that I'm a few weeks late to comment on this, but I > genuinely HATE HATE HATE these unsubscribe requests. > > So here's a quick thing on how to unsubscribe: amazing how much information can be found in an email header: List-Id: For dillo web browser developers <dillo-dev.dillo.org> List-Unsubscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@dillo.org?subject=unsubscribe> List-Archive: </pipermail> List-Post: <mailto:dillo-dev@dillo.org> List-Help: <mailto:dillo-dev-request@dillo.org?subject=help> List-Subscribe: <http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev>, <mailto:dillo-dev-request@dillo.org?subject=subscribe> Sender: dillo-dev-bounces(a)dillo.org Errors-To: dillo-dev-bounces(a)dillo.org -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

July 4, 2006

Re: how do i unsubscribe?

by Andrew A. Gill

Yes, I know that I'm a few weeks late to comment on this, but I genuinely HATE HATE HATE these unsubscribe requests. So here's a quick thing on how to unsubscribe: <http://www.things.org/~jym/fqa/unsubscribe.html> How To Unsubscribe From Any Email List By Jym Dyer I'm on a lot of electronic mailing lists. A deluge of "unsubscribe" and "take me off this list" messages on multiple lists inspired the following, which I send out whenever it's needed. The feedback I get tells me it's useful. When you send "unsubscribe" requests to an email list, it lands in the mailboxes of hundreds of people who can't unsubscribe you. I can't unsubscribe you. Try the stuff below. Clip 'n' save these instructions for future reference. =============8<=============Cut-Here=============8<============= How To Unsubscribe From Any Email List 1. Look at the messages you've been getting on the list. Do they have "how to unsubscribe" messages near the end, or an email address to use in a "List-Unsubscribe:" header at the top? If so, follow those instructions. 2. Most lists these days, including all lists hosted by the big two (Yahoo! Groups and Topica), have an "-unsubscribe" alias for this purpose. For example, if you're on the WHATEVER list, either WHATEVER-unsubscribe(a)yahoogroups.com or WHATEVER-unsubscribe(a)topica.com would be the right address to use. (For the rest of this memo, let's assume that the WHATEVER list is at example.com -- that is, the alias is WHATEVER(a)example.com. If the list has a name like "WHATEVER-L", you might try steps 6 and 7 first.) 3. Otherwise, first send a request to the "-request" alias. For our example, that would be WHATEVER-request(a)example.com. This is often read by a human being, so write accordingly. In theory, all email lists are supposed to implement this address (though Yahoo! Groups does not). 4. If you get no response from the above, send mail to the "majordomo" alias. That's majordomo(a)example.com for our example. If the list is administered by the majordomo software, you'll get instructions for unsubscribing mailed back to you. 5. If you get no response, send mail to the "owner-" alias. For our example, owner-WHATEVER(a)example.com. This should go to the human who administers the list. 6. If you get no response, send mail to "LISTSERV". For our example, that address would be LISTSERV(a)example.com. The text of your message should be "SIGNOFF WHATEVER". 7. If you get no response, send mail to the "listproc" alias. For our example, that address would be listproc(a)example.com. The text of your message should be "unsubscribe WHATEVER". 8. If you get no response, send mail to the site "postmaster". For our example, that address is postmaster(a)example.com. Mention that you tried the previous five steps, to no avail. 9. If you get no response, send mail to "root". Our example address is root(a)example.com. Mention that you tried the previous six steps, to no avail. 10. If -- and only if -- all the above fail, send a message to the list itself. Make it courteous, particularly since the vast majority of the people reading it can't do a thing about it. The message should say something like, "How do I get off this list?", not "UNSUBSCRIBE." Try to avoid setting off a bunch of "me too" messages by saying something like, "Please don't chime in with a bunch of 'I want to unsubscribe too' messages." It's ridiculous that there are so many different ways to do this, and consequentially, so many email lists cluttered up with "UNSUBSCRIBE/ME TOO" messages. You'd think there'd be a standard of sorts, and there is: the "-request" alias dates back to the early days of the Internet. Smart systems like majordomo actually (1) handle messages that were sent to the "-request" alias and (2) filter out the "UNSUBSCRIBE/ME TOO" messages. It's a shame that newer stuff has come along that doesn't do either of these things, but since it's on the web, people seem excited about it (gee whiz!) even though it's a huge step backwards in technology. The "-unsubscribe" alias is a newer standard that's starting to gain ground, but that's no help for many of the older lists that haven't gotten around to implementing new features.

July 3, 2006

Re: [Dillo-dev] how do i unsubscribe?

by Kelson Vibber

Right here: http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev There's an unsubscribe form at the bottom of the page.

June 12, 2006

how do i unsubscribe?

by mike obrien

most of the time, i have no idea what tf you guys are talking about. mike

June 12, 2006