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
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
