[Dillo-dev]Looking inside the cache
by Jorge Arellano Cid
Hi there!
On Mon, 26 Jan 2004, Dylan Dawkins wrote:
(it took some days, I'm pushing the next release...)
> Its extremely fast and has a small footprint (very important).
Yes. I ask because very often, appart from the speed, people
mention: stability, simple&easy UI, clean code and that it works
OK on low CPU/memory systems.
> For my
> patch I actually only use the urls that are currently held within the
> history list already.
So you're trying to find an URL in the cache...
> But I can see how that trying to match what's in
> the history list to what the user is typing could yield some small loss
> of security (if anyone is peeking over the users shoulder).
I thought you were to keep an archive with the visited URLs;
clearly a privacy problem, but if it only scans what's on memory,
it is not much different from what we have now (stack history).
> The problem
> being solved, is not having to type long urls out all the time. And I
> suppose the bookmark idea solves that problem, except when the number of
> bookmarks becomes large enough that typing the beginning of your url, is
> quicker than looking for the specific bookmark.
Looking inside the cache has several interfaces in browsers:
* Tabs
* Cache list (stack history back/fwd)
* History list (full list of the cache)
* Predictive URL input
* Search dialogs
Every one of them have good points and some weaker ones; I
assume that's why there're so many mechanisms! :)
Given the nature of Dillo, having them all is not a good idea.
The point is to find a few that cleanly solve the problem
(i.e: enough to solve the problem, and that integrate well with
the UI model). I'm not quite sure of what should it be at the
moment...
For instance, a long time ago we thought with Eric that having
a "linear history" menu was a good idea (all the visited URLs
sorted by time of visit). That's why we have history.[ch].
It should pop up with the current one highlighted and a right
click would make a new popup, this time filtered by the
highlighted URL's host (all the visited URLs coming from that
host).
An interesting idea that has been waiting for a proper
implementation. It has the plus of allowing access to the whole
list of visited URLs, but may start to get clumsy as the URL list
grows.
At this point, I believe the best interface is a search dialog:
Search cache:
In Url : _______
In Title : _______
[Search] [Clear] [Cancel]
It can be hooked to a right click menu on the (Web) Search
icon. That would also allow to add other search URLs as
dictionaries, packages or whatever, configurable from dillorc.
One feature of the cache search would be to return the linear
history when the input camps are empty.
Maybe this interface, plus tabs (or page marks; think of tabs
listed in a popup menu) is all we need.
>
> I wouldn't mind working on the https part of the browser. My skills are
> mainly with C++,C embedded coding. I have good experience with the
> security
> Like SSL tunnels VPN rijndael support in VPN, elliptic curve
> cryptography (just a hobby). I am a computer scientist and a Linux
> devotee, that started using Linux fulltime from RedHat Linux 6.0.
Great. After the release, I'll be preparing the basis of the
https dpi server (as requested by Madis) so you both can work on
it.
By now you can study the downloads server to get the idea of
how it all works (of course you'll need to read the dpi docs
too). After you get enogh knowledge and are confident enough, you
can start working with Madis on https or I can send you a
grphical download plugin that needs polishing.
> I have not worked with FLTK, but it looks like a good idea.
After a testing a prototype GTK2 Dillo, and also after probing
the GTK2 version of XFCE, I believe the best path is to abandon
GTK2. There's an interesting thread in the list.
FLTK would certainly come with a lot of porting work, but I
believe there will be enough developers to do it!
We're waiting for Sebastian's green light on it to start. He's
the main author of Dw, so he's the person that knows best what it
would take to port Dw to FLTK.
> I have
> subscribed already. What specifically is your role in this project?
Founder, mantainer, lead developer, webmaster, ... :-)
Cheers
Jorge.
20 years, 9 months
Re: [Dillo-dev] current no-cache patch?
by higuita
Hi all
not wanting to start a flame war, so any reply, please send directly
to my email
i feel that i have to reply to this, because many newcomers dont
really understand dillo, nor take the time to read past posts
in the mailling list to know why dont have replies to some topics.
please note that i'm not a developer, not even a small one,
just a user and "beta tester" old enough in the mailling list.
>> i posted this some time ago. are there any developers on the list?
yes, but there are only 2 main devs, both usually very busy and
try to spend more time coding than reading emails.
on that message, there wasnt many things to say... no dillo dont
have any expire support, and no one knows when it will have one
because the main priority is now the port to FLTK
> Hopefully, dillo will move ahead, and in particular do things such as frame
> support, tabbed browsing, etc. (Apparently, several pactches were done, but it
> was never incorporated into dillo for reasons best known to the head
> developers.)
if you had read the mailling list better, you would find that the
frame patch was welcome, but it was also huge and changed many of
the dillo internals.
it was asked to break the patch in small ones to be easy to audit
and merge, but instead (and unfortunately ) the patch maker kept
adding new thing, making the patch even bigger.
after several other things, the patch stop being updated and
with dillo code improving, it stopped to work and was (still) too
big for someone to keep it in sync or break it up.
> What dillo seriously needs is to incorporate stuff whereby browsing becomes a
> good experience.
dillo will never merge code just because its useful, it must also
follow the same line as the existent code... dillo was build to
be small and fast, not to be a new mozilla
just because there is a patch to call external programs based
in the mime type, that doesnt means that it the best way to do
it, and even worst, if its safe to do it...
> It is no good if we have to use another browser even 20% of
> the time.
again, dillo isnt set to be the next mozilla...
if you want a free software browser that tries to to
replace it, go check konqueror... not dillo, w3m,
lynx and links
> revenue for the project: is anyone seriously going to pay into a browser which
> will never be able to support frames, javascript, etc?
if its FAST, light, render most pages OK, why not?
do you really wants to run mozilla in a palmtop?
i spend most of my web time in dillo, its fast and secure,
surfing is again fun... but yes, i keep a copy of firefox
for those pages that are more complex
> There are a lot of people willing to contribute to dillo, it appears, and the
> main developers could/should use some of the talent.
good, then let the main devs port dillo to fltk and release it
and then start building on top of it, following the dillo
philosophy and code rules
dillo is set to be modular, if you want some new feature, build
a dpi (in any language) that talks the dpi protocol, and then
only the people that want it will use it.
let the main dillo code be about render html code and speak
with the dpi processes
if you want to help and cant code, donate some money, if the
devs dont have food, they have to spend time doing other things
to feed themselves and less time to improve dillo.
> Clearly, one possibility is to fork dillo.
some people already tried it, to build a "have it all dillo",
the result was that it was dropped a few weeks later...
most people that use dillo like it because its fast and
light, having more features is just a bonus (or not, to some
people, it *must* have a disable switch... cookies, javascript,
frames, plugins, etc are not welcome to some people)
higuita
--
Naturally the common people don't want war... but after all it is the
leaders of a country who determine the policy, and it is always a
simple matter to drag the people along, whether it is a democracy, or
a fascist dictatorship, or a parliament, or a communist dictatorship.
Voice or no voice, the people can always be brought to the bidding of
the leaders. That is easy. All you have to do is tell them they are
being attacked, and denounce the pacifists for lack of patriotism and
exposing the country to danger. It works the same in every country.
-- Hermann Goering, Nazi and war criminal, 1883-1946
19 years, 1 month
Re: [Dillo-dev] Problems with gziped content encodings pages and proposal
by Jorge Arellano Cid
On Tue, Aug 29, 2006 at 06:40:40PM +0200, Diego Sáenz wrote:
> Ok, second try(i have changed a pair of things):
>
> The general ideas are to enhance dpid to manage DPIs using services (Like documentation suggest) and to add code to dillo to implement protocols DPIs (without hardcoding them in dillo core), mime handlers DPIs and maybe scripts languages DPIs and content
encodig DPIs(now encodigs DPIs are in doubt after your mail)
>
> Dpid will need configuration lines(in dpidrc) to associate server name with DPI path(A dpi dir based path allow a DPI to serve more that one service(in this proposal a javascript DPI will serve protocol_javascript, script_javascript and maybe
mime_text/javascript services)).
>
> When dillo finds a protocol that it not handle in core (currently it handle http:, about: and dpi:) it ask for a service for that protocol(to dpid) and dpid returns the DPI from the configuration file(really a socket to comunicate with it). For the
service name dillo add the protocol name to the "protocol_" string.
>
> The lines in dpidrc for current services can be this:
>
> protocol_file=file/file.dpi
> protocol_ftp=ftp/ftp.filter.dpi
> protocol_https=https/https.filter.dpi
> protocol_data=datauri/datauri.filter.dpi
>
> I think i will allow the use of '*' to match any(even none) char until end of string in the configuration file. '*' will be checked last. It can be used by a ProtocolNotSupported.dpi that show an error or a page with protocols DPIs to download.
>
> The dpidrc line can be like this:
> protocol_*=misc/ProtocolNotSupported.dpi
>
> For mime types it works similar. When the user clicks on a link or uses the url bar to view a mime type not handled by dillo the mime type is addeded to the "mime_" string to get the service name(dillo currently handles mime_text/html, mime_text/plain,
mime_text/*, mime_image/gif, mime_image/jpeg, mime_image/png). When a not handled mime type is open because a page load dillo add the "_inlined" string to the previous string(example: For a bmp file used like image in a html page dillo will try the
mime_image/x-bmp_inlined service)
>
> The use of '*' wildcard allow the use of one DPI to manage both services with only a configuration line if user wants.
>
> About mime type check/detection i am thinking on diferent options (mime detection/check go before mime DPIs)
> 1a. Fixed service called for pages without mime types and ocet/stream (using this like unknown mime type) that returns a detected mime
> 1b. Fixed service called for pages without mimes and for a list of configured mime types in dillorc
> 2a. Check service per mime type with service names like mime_check_MIME/TYPE. Dillo send actuall type so the DPI handling the service can do something if detected mime is diferent from the server sended one.(ask the user, ignore error, stop load ...)
> 2b. Like 2b, but only ask for a list of mimes configured in dillorc
>
> Scripts and content encoding work similarly.
>
> For more details i can send how the dpi tags will be and more about dillo-DPIs communication and dillo internal changes.
At this phase I'd appreciatte much more the "general picture"
rather than some implementation details.
I mean. What's the problem you're trying to solve? What's the
scheme you propose? Have you tested it to suit current
functionality and maybe other problems too?
For instance, if you click over a network radio link, it's not
a good idea to use dillo to download the link data and to pass it
via dpi to a dpi-radio plugin (and worst, to cache the stream!
:). It's much better to cut the network connection from dillo and
to handle the URL to a dedicated radio-stream program.
In the case of a PDF. It would be nice to save the data to some
temporary directory while you pipe it into xpdf or to let the
user choose whether to save with a dialog.
Same for a movie stream, etc, etc.
>
> > With regard to gzip encoding: zlib can do gzip decoding, and as
> > it is already linked in Dillo, gzip decoding can be implemented
> > inside Dillo (not using a dpi).
>
> Oh, i forgot it.
Will you implement this?
>
> > This also avoids multiple dpi passes. For instance with dpi-
> > decompress, gzipped isolatin2 would require one dpi pass for
> > uncompress and another for latin2 to utf8.
> >
> > Inside-Dillo decoding also allows the idea of having a
> > compressed cache in the future.
>
> I unknown if i can implement content encoding in dillo
> internals so i will move it after dpid changes on implementation
> complex.
IMO this is much simpler tan what you're willing to try first.
Beware.
--
Cheers
Jorge.-
18 years, 2 months
Re: [Dillo-dev] An odd request, I know...
by Tom Barnes-Lawrence
Hi again,
On Mon, Jan 19, 2004 at 06:29:16PM -0300, Jorge Arellano Cid wrote:
> > Firstly, I'd like to say I've been using Dillo for over 2 years now,
> > and find it fantastic. Well, apart from a few little details (which
> > I'll probably post to the list in a couple of days, when I'm less
> > busy). So anyways, very well done for this piece of software!
>
> Thanks for your comments. A long time user, that's good news!
Hehe, you haven't heard my complaints yet ;) Don't worry, they're
not so bad, and I'm not going to go making demands. Here you go:
-I understand you not wanting the referer info being sent, even if
it does make the logs from my hit-counter a bit less useful, *but*,
some sites do seem to use the referer tags to work out if you're
accessing their images, etc deep-linked from some other page.
I'm afraid I can sort of sympathise with this, as the idea of
"stealing bandwidth" does have quite a lot of truth in it (it
does cost them money).
So, perhaps (as someone else suggested) Dillo could have some
button or menu option, etc that we could click to allow the
referer tags to be set temporarily for pages that need them?
Or alternatively, images on pages could automatically have the
referer tags set for them, or they could be used for accessing
*any* other file on the same server perhaps. Just thoughts.
-It's probably because I'm using a snapshot of 0.8.0-pre from about
November with Frank's tabs patch (OK maybe the tabs patch doesn't
affect this), but once or twice I've found my load average go way
up, and looking at PS, found dpid spawning the https plugin
repeatedly (with each one dying again so there was only ever one
at a time). IIRC this happened (some time) after quitting Dillo.
Perhaps this is one of the things you've fixed since then.
-It's great that the cache is used so aggressively with static
content, it keeps things very very fast, keeps the network
usage down, and is very useful when the connection goes down;
but it does seem to get used in many places where it really
shouldn't, such as dynamic content (revisit certain CGI scripts
and you just get the cache), and that problem with images- where
if a screenful of images stops loading, refreshing will *not* reload
the half-done images.
OTOH, it's *good* that dynamic content doesn't get reevaluated when
I press the *back* button. That's a PITA when other browsers do that,
as I usually just want to go back to where I was before.
-MOST important to me: Bookmarks. I like the way Dillo now has
bookmarks shown as a web page instead of a menu, I like that it allows
us to put them into categories, and I like that the DPI system allows
the bookmarks to be controlled by a separate program.
Unfortunately, bookmarks are still one of the main reasons I still
use Konqueror (despite the stupid crashes): I have lots of them,
last time I tried to work it out I calculated maybe a thousand-
and a great many of these are *not* pr0n! The only way I can cope
with so many of them is having them organised into a very deep
heirarchy. But not only does Dillo's bookmarks program not allow
this, but it has every single bookmark shown on the same page! The
scrollbar control is tiny!
So, I'd love it if the bookmarks code stuck each section in its own
page, and let me nest one section in another. Perhaps the current
version is only temporary, so you'd have time to work on other
stuff, and all this is already planned, but I thought I ought to
mention it because *this* is one thing that would really make
Dillo great for me. I'd have a go at this myself, but I've already
got lots of other things to do. OK, I suppose you do as well.
That's it, really. For me, the problems are definitely oughtweighed
by Dillo's good points, like the stability and speed, I just want
to be able to use it a lot more!
> > seeing, every time I started Dillo, the tidy little splash screen...
> >
> > ...So basically, would Jorge (or whoever is responsible for that) mind
> > if I effectively copied the HTML?
>
> Yes I do mind...
>
> I find it great if you reuse them! Go ahead.
Excellent! Thanks very much. In fact, Sunny Raspet had already offered
to let me use some of his layout, but as I'd already got my macros
to churn out Dillo's tags, I figured I'd wait and see instead.
> I'd be awful if it comes the day when those things can be patented
> or copyrighted.
Yeah, I know what you mean.
> PS: Please let me know the URL after you finish.
It's not strictly finished, there's various pages missing, but:
http://www.angelfire.com/super2/duologue/
Thanks,
Tom Barnes-Lawrence
20 years, 9 months
[PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)
by Melvin Hadasht
[Henning, you may be interested: the patch implements a --reload option]
Hi,
To implement the server and remote commands feature in Dillo, I'm going
to go step by step. First, I'll implement commands to control
Dillo at startup time, then I'll implement the server mode (where a Dillo
instance can send the aforementioned commands to another Dillo
instance). This is because I may try two differents approaches for the
server mode part and because the commands are just a generalization
of the command line options and can be implemented separately.
Here is my first step: implement commands (like -c "open(URL)").
Patch is attached and is against CVS version.
This is a generalization of the command line interface, and in fact, most of
the old command line options are translated to a Dillo -c command. The
advantage of such approach is that the commands can take optional parameters, like in:
dillo -c "open(URL newwindow reload=10 fullwindow=yes)"
which is approximately equivalent to:
dillo -f -r 10 URL
The commands are passed to Dillo as arguments to the -c, --command command line option:
dillo -c "open(http://www.google.com)"
1. Command Syntax
The argument to the -c command line option is of the form:
CMD([STRING][ PARAM=VALUE]...)
CMD: command name
STRING: first and generic argument: in general a URL or yes|no
PARAM: name of optional parameter
VALUE: value of optional parameter. Currently, only booleans (yes|no)
and integer values are supported. Boolean value can be omitted, in which
case the value is considered to be "yes". Integer value cannot be omitted.
Parameters are separated with a single space (no commas, to simplify the
parser)
Commands can be divided into two groups: actions commands, and
options commands
2. Action Commands:
They do some action: currently implemented commands:
open(URL
[ fullwindow[=yes|no]]
[ reload=SECONDS]
[ spamsafe[=yes|no]]
[ xid=XID])
parameters speak for themselves. The "reload" parameter is a new
feature: it allows to reload the URL each SECONDS seconds. The reload
is halted when the page is not viewed and restarted if the user comes back
to it.
exit()
exit the instance. This will be useful when passed to another Dillo instance
running as a server.
Other commands can be added. The framework is quite flexible and
extensible.
3. Options Commands
These commands set some options that will affect the following commands. For example, the parameters used in the open() command
act only on that particular URL. But it can be useful to be able to set
some defaults values. The currently implemented commands that
influence these defaults are:
fullwindow([yes|no])
reload(SECONDS)
spamsafe([yes|no])
xid(XID)
all open() commands that come after these options commands will
have these default values, unless explicitly overridden.
4. Examples:
dillo -c "open(http://www.google.com)" -c "open(file:///home/mhadasht/test.html newwindow spamsafe)"
will open two windows: the first with google, and the second with the local
file opened in spamsafe mode.
dillo -c "reload(10)" -c "open(http://www.freshmeat.net)" -c "open(http://news.google.com newwindow)"
will open 2 windows and will reload both URLs each 10s.
This is equivalent to:
dillo --reload 10 http://www.freshmeat.net http://news.google.com
5. Implementation details:
5.1. Command Line Parsing
Command line options other than the help/version options are translated
into a -c command and stored in a list.
The list of commands is then executed (or, when the server mode will
is implemented, sent to another Dillo instance)
5.2. Reload Function
a URL can be set to auto-reload itself if it is currently viewed. For that,
a new member (reload_interval [milliseconds]) to DilloUrl is added and
set with a_Url_set_reload().
Each BrowserWindow can trigger a timer function if the viewed URL (Nav_open_url()) has a non-zero reload_interval. (As soon as another URL
is viewed, or when the BrowserWindow is destroyed, the eventually
pending timeout function is removed.) The timer is of the
one-shot type: when it is triggered, it requests its BrowserWindow
to reload the URL, then it stops itself.
There is currently no UI to start/stop an auto-reload of a URL, but it is just
a matter of using a_Url_set_reload() to a non-zero or a zero reload
interval.
6. Remark
The -c command and the normal command line options can be seen
as two ways of doing the same thing: passing commands to Dillo.
But the -c command is more generic and flexible and has a more powerful syntax.
7. Future Plans
I plan to implement the server mode. After reading the dpi doc and source, I found that it cannot be used to make Dillo act as a plugin unless we accept to have only one Dillo server. This is because the socket names are tightly linked to the service name. Each service has only one socket. Whereas Dillo servers must have a distinct socket. If the we add another argument to the "start_plugin" cmd:
<dpi cmd="start_plugin" msg="dillo" param="SERVER_NAME">
and if we modify the socket naming scheme, then it could be possible. I have to think about that again.
But I may still use the communication infrastructure of the dpi.
If I find this overkill, I'll revert to the straightforward approach I used
before, that is, I won't use the dpi framework.
OK, it's late, I hope I managed to be somewhat clear...
Cheers.
--
Melvin Hadasht
21 years, 2 months
Re: [Dillo-dev] [patch] Cleanup of IO.c
by Diego Sáenz
In few words: more code and less words. Come on to code it to have
something to compare. I will help you if you want and i think that more
people in the list will help too.
About feedback from developers they are always like that. I think they
are busy.
I do not understand your disapointing very well and maybe because that i
sound rude, excuseme then.
Diego.
"Indan Zupancic" <indan(a)nul.nu> escribio:
> Hello,
>
> The patch was downloaded 14 times, and zero feedback... Great. I
> wanted to cleanup http.c in a similar way, but never mind.
>
> I feel sad and frustrated because of the lack of feedback from the
> Dillo developers. I tried to improve Dillo, to add some extra
> features. Dillo is a nice browser and I thought that spending my time
> on it would be appreciated, but it seems I was wrong. I give up, I'm
> not going to waste my time on improving Dillo while all efforts are
> just ignored or told to be useless because of the "that mess is fine
> as it is now" attitude. If the neutral and obviously (somehow I start
> doubting that now) improving IO cleanup patch is ignored, then what
> chance do I have with cleaning up the CCC horror...
>
> To give you an idea how bad it is:
>
> There are at least 24 ways of calling a ccc function. That is a
> conservative estimation, because I only counted the possible parameter
> combinations(values, types), you still need to know which variant of
> the many you need to use with a certain module. Also I counted only
> the ccc functions of the IO, cache, file, http and dns module, I
> didn't count the dpi and capi modules(just didn't come that far).
>
> This mess means that modules can't communicate transparantly with
> eachother, because they need to know exactly which data to give,
> implicating that they need to know with which module they're talking.
> That makes the whole CCC construction worthless, because one of it
> goals, or so I guess, was to have a chain like communication where
> linked elements could do their's stuff and notify the next element
> without knowing anything specific about eachother. With the current
> situation the CCC structure only adds unnecessary complexity to the
> overall code, obfuscating it.
>
> If that's what you want, fine, but then say so, instead of saying that
> it's hard to replace. Yes, duh, you made a spaghetti mountain, of
> course it's hard to clear that up. I truly hope that the rest of Dillo
> is cleaner, and from what I saw of it, the GUI part doesn't look that
> bad.
>
> Next grief: DPI's.
>
> What was meant like a simple plugin system turned out to become the
> sauce over the spaghetti, to stay with the previous metaphor. It seems
> like the cache api code handles dpi's differently, at least there is
> plenty dpi specific code in the capi.c file, so it seems like it's in
> the wrong place. I mean, if it's not part of the cache api, then what
> is it doing in that file? capi.c has even it's own CCC function only
> for dpi's, so an extra module in a wrapper??
>
> Worst is, making a dpi isn't as simple as making a CGI, as it should
> be. And of course the whole dpid construction makes no sense. not
> really anyway: you can find all the dpi's the same way as you find the
> dpid... Sure, dpid has some minor advantages, but everyhting has
> _some_ advantages.
>
> All the dpi code (not including bookmarks.c) is 14K big, just imagine
> what you could implement with so much code (native ftp support comes
> into mind). Not even talking about how much resources the dpi's use,
> because they have such an awkward interface and need to do things that
> Dillo already could do, duplicating code and features.
>
> I'm aware that certain people already wasted too much time on the
> current dpi code, so it has zero chance of being changed, I'm not so
> naive to think it would. I just give my oppinion on it. I had put my
> hope on the IO/CCC mess.
>
> Sigh, if only Dillo went the GTK2 way, then I could say goodbye
> without trouble, but now it seems like Dillo will use FLTK it's even
> more depressing.
>
> ---
>
> Oh well, enough rambling, if someone wants an updated version of the
> installer, then say so. I won't do much with the https patch, because
> as it is now it can't be improved much without cleaning up IO, CCC
> or/and http, or at least without merging the IOData structures, so
> more than synching with CVS and tiny changes won't happen.
>
> Good luck and take care,
>
> Indan
>
>
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev(a)lists.auriga.wearlab.de
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
20 years, 11 months
Dillo article precisions
by Jorge Arellano Cid
Hi Rick,
It's being a long time since my last article at linuxdevices,
receive my greetings from Chile!
With regard to the new article:
http://linuxdevices.com/news/NS4370323584.html
It caught me by surprise. There was a thread in dillo-dev and
some users suggested that campaign. I was commenting on gross
factual mistakes in the wiki when it was announced that an
article was live at linuxdevices.
It's good to see our users' interest in keeping the project
alive, so I'll comment the article here so you can correct and
improve the article:
> A project to create an ultra-lightweight web browser for use in
> embedded devices and other resource-constrained hardware has
> issued a plea for financial help. The Dillo Project says it needs
> to find a corporate sponsor in order to add anti-aliased text,
> CSS, Javascript, and internationalization/localization support.
We've almost finished the port to FLTK2, and it already has
anti-aliased text. (Dillo doesn't compile with FLTK1)
FLTK2 uses UTF8 and provides antialiasing so it solves the
problem of using GTK1 (this was one of the reasons for GTK1 to go
GTK2).
UTF8 also makes it easy to add i18n and l10n without breaking
things inside the browser.
I point this technical details because unofficial patches have
been developed for antialiasing, i18n and l10n for GTK1. This is
a good workaround but not a long term solution.
>
> (Click for larger screenshot of Dillo)
Here you'll find a screenshot of dillo-fltk2:
http://www.dillo.org/test/ph2.png
(it shows antialiasing)
>
> Dillo is a very lightweight (about 350 KB) browser supporting a
> subset of HTML, CGI, SSL, and cookies.
And plugins.
+ Images (GIF, PNG and JPEG)
> Dillo is not really
> practical for browsing the modern Internet, due to missing
> support for frames, CSS, Javascript, and other commonly used
> standards and protocols. It also lacks support for anti-aliased
> text, something even Linux desktop users have long taken for
> granted, and appears to have only rudimentary HTML error handling
> capabilities.
The HTML error handling has improved a lot (the bug meter can
atest that), but yes, error handling is not as advanced as with
Firefox.
Anyway, sometimes there're pages with a few hundred mistakes
handled gracefully. ;-)
> Nonetheless, Dillo is extremely fast and lightweight, using less
> memory in some cases than popular text-based browsers such as
> lynx. And, since it supports CGI, it could be useful as a
> framework for simple device interfaces based on Web standards,
> such as survey kiosks and other closed, "walled garden"
> applications.
BTW, the new Dillo with a statically linked FLTK2 is about
820 Kilobytes.
>
> Additionally, Dillo is popular with web developers due to
> excellent HTML error reporting.
:-)
>
> Dillo is expected to gain support for anti-aliased text after its
> development team completes a port to FLTK (fast light toolkit,
> aka "fulltick").
[Already there, see above]
> However, founder Jorge Arellano Cid appears
> adamant that funding be located prior to release of his
> nearly-complete FLTK port, according to a "save Dillo" campaign
> page hosted here.
True.
The situation is this: there're two core developers. We need at
least to be both working on Dillo full time (ideally three devs.)
otherwise the project would lag behind the moving target that
Internet browsing is.
Sebastian (the other core developer) is employed fulltime in
Germany so he has almost no time to Develop. I don't have funds
to keep on working fulltime too, so if there're no funds the
project will loose the main developers and their knowledge.
With regard to releasing. That's what I've done for 6+ years
with GTK1 and no funding happened ;-).
If there were more interested developers in working with Dillo
(lets say 6 serious and qualified people) I would consider
releasing because the project could advance in that case.
Believe it or not I asked in dillo-dev, and there was only one
answer from a dev that could put 4 hours/week and that had no
FLTK2 knowledge nor on Dillo internals.
Given the current situation, the best option seems to remain
closed until funding happens.
>
> Other ongoing Dillo development efforts reportedly include CSS
> support (said to be "70 percent complete") and JavaScript
> support, as well as additional internationalization (I18n) and
> localization (l10n) features.
I reported 70% on CSS. This is on the FLTK2 branch, not from
external efforts.
The interesting part is that we paved the way for all these in
the newest branch, so now it's much easier to develop them over
the new code base than with the old branch.
A rough timeline estimation would be near 2 years to have the
whole set: antialiasing, CSS, I18n, l10n, Frames, Tabs, SSL and
good Javascript.
We could make a release in 6 months and thenceforth go on
incrementally adding features in any desired order (probably this
would be up to the sponsors' needs).
> Additional details about Dillo can be found on Dillo's official
> funding presentations page. For additional background, be sure to
> read Cid's 2002 introduction to the browser, here.
>
> The Dillo project previously sought funding in February of 2004,
> and was successful in obtaining a one-time grant through the
> Linux Fund.
Thanks a lot for your time and commitment.
--
Cheers
Jorge.-
18 years, 1 month
Re: dpid
by Jorge Arellano Cid
[we've had this thread for a long time outside dillo-dev, it
has some interesting information so I'm switching to dillo-dev]
Ferdi,
On Thu, 4 Dec 2003, Ferdi Franceschini wrote:
> Hi Jorge,
>
> On Tue, Dec 02, 2003 at 09:03:08AM -0300, Jorge Arellano Cid wrote:
> >
> > Hi Ferdi,
> >
> > > > [...]
> > > > Unfortunately the dpid is showing some problems with some https
> > > > urls (also with some ftp ones). It sometimes ends in a loop of
> > > > endless forking of dpi programs.
> > > The https dpi appears to be implemented as a filter type plugin but it is installed as
> > > https.dpi and not https.filter.dpi.
> >
> > Oh!
> Does https work now?
It does partly! (with the dpi-cache patch I'm developing).
I'm planning to develop https.dpi as a dpi server so it can
directly link against SSL lib or GNU TLS, instead of using wget.
This ends the forking and allows for an easy implemetation of
connection caching.
BTW, https pages render OK with my tree, it's just the lack of
reuse of the same connection what I suspect keeps it from working
fully. I need to test a bit more too.
Note: is there anybody here interested in working on the https
dpi. I can quickly make the base (dpi server instead of filter)
and then is a matter of knowing SSL or TLS and start implementing
connection caching (no need to know about dillo internals).
> [...]
>
> > The idea is interesting. Perhaps looking at the Volume III of
> > Douglas Comer's book is well worth a try. I skimmed it yesterday
> > and it has a lot of theory about this kind of servers. Do you
> > have that volume?
> I'm affraid not, I'll see if I can hunt down a cheap copy.
Worth a read (although I prefer Richard Stevens' books).
> > Now that filter dpis can run in parallel, they're also showing
> > the fork hog problem. I'm attaching an example page; drop it
> > inside an ftp directory of your local machine and try loading it
> > from dillo.
> >
> > WARNING: don't do it on a server, it can bring down the machine!
> > (I've had to switch-off mine to recover).
>
> > Dpid keeps on forking new instances of the ftp dpi until the
> > machine is full of new processes. It looks like when the first
> > child can't accept the connection, dpid regards the old request
> > as a new one and forks another child.
> But dpid accepts the connection from dillo on behalf of filter dpis so any
> connections seen by dpid must be new requests.
I'll double check that.
(It could be that the service FD keeps showing in the select
call because it was connected, but never serviced...)
> I set up an ftp server on my old 486 and tried out the test page.
> And it killed my Xserver!
> It also really upset inetd on my 486 which was
> running ftpd, inetd reported looping ftp connections and terminated the
> service. It also refused further connections for some time afterwards, however
> you can get things back to normal by restarting inetd.
>
> I redirected the messages to a file and tried again, I found multiple
> occurences of the following message:
> <q>
> Dpi_get_server_uds_name:: /tmp/ferdi-khv5us/ftp.filter.dpi
> </q>
>
> this suggests that dillo is actually making multiple requests.
> I also found the following error messages from dpid:
> <q>
> main.c:153: get_command: dpid tag is NULL
> : main.c:323: main: get_command failed
> </q>
>
> I still don't know what's going wrong, I'll have another look at this in the
> next couple of days, I hope the above information helps.
I'll check it too.
> > Some time ago I started a download with a graphical dpi, and
> > the downloader was open twice! This hints towards the presence of
> > a race condition.
> What do you mean by graphical dpi?
It's an idea I've been preaching on for a long time. But nobody
seems to believe until they see! :-) --Blame St. Tomás.
> Is there a shiny new downloads server that
> I'm missing out on?
Yes! MUUUAAHAHAHAHAHAHAA!!
It needs polishing but illustrates the idea pretty good. You'd
be surprised at how simple it is. BTW, it was developed by a
complete newcomer to dillo I was advicing.
I'll send it to you and Sebastian (to illustrate part of a
response I owe him about preferences).
List: I'll review the latest version and decide whether to
share it in its current state for polishing. The required
knowledge to work on it is minimal: just GTK+ (the server part is
already done). More on this later... Anyone interested?
> > a race condition: if the father continues running before its
> > child accepts, the request may be served twice or more times.
> Only if the child terminates before it accepts.
> This is because dpid clears the downloader's socket from the
> socket_set which
> 'select' is watching before forking and the socket is then set again by
> dpid.c:handle_sigchld() when the child terminates.
Time to review.
Regards
Jorge.-
20 years, 11 months
Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)
by Jorge Arellano Cid
On Wed, 2 Jun 2004, Madis Janson wrote:
>
> On Tue, 1 Jun 2004, Jorge Arellano Cid wrote:
>
> > The current prototype for SSL (using dpi) provides for an easy
> > way of implementing connection caching, and for asking the user
> > (using dillo's API) whether to continue on unverified
> > connections, the SSL part of this verification is not yet done
> > though.
> >
> > As Madis put it:
> >
> > > Most important thing missing from the ssl specific code is certificate
> > > verification - it MUST be done in order to have any actual security.
> > > In its current form it just gives a way to access SSL sites, but not
> > > secure access.
> >
> > I know people look forward to the day when they can complete
> > their online shopping with dillo, but we must be very careful to
> > provide real security. This is key.
>
> I hope to look at it (probably in july).
Good!
> > Unfortunately I'm not an encryption expert, and we need some
> > help from a savvy guy (the chances of a SSL freshman to make
> > mistakes is very high).
>
> Yes, it is a hard thing. There were for example a same SSL certification
> chain handling bug in IE and Konqueror.
>
> It would help, when someone would write a library-like code for verifing
> peers certificate with simple interface. I'd look the existing
> implementations in Konqueror SSL plugin and Mozilla for reference.
I read a lot of the GnuTLS manual, and found some interesting
facts and functions that could help. Including a function
somewhat like what you sketched:
> For example something similar to this:
>
> /**
> * Check the peer's certificate.
> *
> * \param connection current SSL connection
> * \param result the verifications result
> * 0 - ok
> * 1 - we don't know wtf it is, ask confirmation
> * and tell user, that good answer is NO.
> * 2 - error, couldn't do the verification
> * ....
> * \return message for user
> */
> char* chain_verify(SSL *connection, int *result);
>
> /**
> * User said, that he likes that one...
> *
> * \param cert certificate to remember
> * \return 0 - error (message in openssl error stack), 1 - OK
> */
> int remember_certificate(X509 *cert);
>
>
> > I'd love to have a TLS based dpi for https (TLS lib is GPLed
> > and is a requisite to NPTL, so it'll become as ubiquitous as SSL
> > lib). The current prototype is SSLlib based, but is enough to
> > start polishing and extending the code.
> >
> > Some time ago Madis wrote an SSL gateway for Dillo. After some
> > work, I decided to integrate it through the dpi framework (to
> > empower it with dpip and also to avoid some quirks by using the
> > standard way to extend dillo). That is the current prototype.
>
> http://www.zone.ee/myzz/dillo/https_dpi/https_dpi.tar.gz
>
Here follos an abridgment of interesting information inside the
GnuTLS manual:
<q>
http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html
--
Description:
Technically GnuTLS is a portable ANSI C based library which
implements the TLS 1.0/1.1 and SSL 3.0 protocols, accompanied
with the required framework for authentication and public key
infrastructure. The library is available under the GNU Lesser GPL
license1.2. Important features of the GnuTLS library include:
* Support for TLS 1.0, TLS 1.1 and SSL 3.0 protocols.
* Support for both X.509 and OpenPGP certificates.
* Support for handling and verification of certificates.
* Support for SRP for TLS authentication.
* Support for TLS Extension mechanism.
* Support for TLS Compression Methods.
Additionally GnuTLS provides a limited emulation API for the
widely used OpenSSL1.3 library, to ease integration with existing
applications.
---
Verifying peer's certificate
A TLS session is not secure just after the handshake procedure
has finished. It must be considered secure, only after the peer's
certificate and identity have been verified. That is, you have to
verify the signature in peer's certificate, the hostname in the
certificate, and expiration dates. Just after this step you
should treat the connection as being a secure one. The following
function is a simple example on how to verify a single
certificate. Real world programs should be able to handle
certificate chains as well.
---
/* This function will try to verify the peer's certificate, and
* also check if the hostname matches, and the activation, expiration dates.
*/
void verify_certificate(gnutls_session session, const char* hostname)
[...]
---
Resuming Sessions:
The gnutls_handshake function, is expensive since a lot of
calculations are performed. In order to support many fast
connections to the same server a client may use session resuming.
Session resuming is a feature of the TLS protocol which allows a
client to connect to a server, after a successful handshake,
without the expensive calculations. This is achieved by using the
previously established keys. GnuTLS supports this feature, and
the example resume client illustrates a typical use of it.
---
http://msmtp.sourceforge.net/ (GPL)
Version 1.0.0:
- correctly handle certificate chains in tls.c GnuTLS code
---
Interview (Nikos Mavroyanopoulos):
http://www.gnu-friends.org/story/2003/12/17/14525/717
</q>
Some remarks:
The msmtp project is interesting because is GPLed, and handles
certificate chains, so it can be reused.
The "Resuming Sessions" feature is also interesting because it
could initially account for what we've been calling "connection
caching". (i.e. instead of keeping an SSL socket alive to
communicate with the server, a new session can be requested, and
GnuTLS' "resuming sessions" does the rest).
The documentation is clear and comes with several examples.
Please give it a look Madis.
Cheers
Jorge.-
20 years, 5 months
towards a consistent UI
by Johannes.Hofmann＠gmx.de
Hi,
-------- Original-Nachricht --------
> Datum: Mon, 11 Aug 2008 12:59:32 -0400
> Von: Jorge Arellano Cid <jcid(a)dillo.org>
> An: dillo-dev(a)dillo.org
> Betreff: Re: [Dillo-dev] towards a consistent UI
> Hi,
>
> Well here's my opinion on these UI points:
>
> On Mon, Aug 04, 2008 at 09:50:24PM +0200, Johannes Hofmann wrote:
> > Hi,
> >
> > I really like the way Ctrl-l now just selects the current
> > URL in normal mode avoiding a dialog window.
>
> Me too!
>
> > In fullscreen mode however, the short switch to normal mode to enter
> > the new URL requires a complete redraw of the page contents.
> > Also the contents "jumps" down for the time the location bar is
> > shown. This can be distracting.
>
> Find text also causes a redraw. Maybe avoiding the redraw in
> both cases is a good solution. Not of high priority unless really
> simple to implement.
I think the flicker can be avoided, but that won't stop the content from
"jumping" in the fullscreen case.
>
> > Do we really want to kill all uses of dialog windows? We still have
> > "Search the Web" anyway.
>
> No. Some dialog windows are quite OK, and there's no need I can see
> to ban them.
Agreed
>
> > Also the location of the "IMG ON/OFF" button seems a bit arbitrary.
>
> I like it where it is, but agree on that it may find a better place.
> Together with the other Panel buttons, my be.
>
Yes maybe. I will try that when I have time.
> > How could a consistent user interface of dillo look like?
> >
> > Here is my proposal - just to start the discussion:
> >
> > * Everything is accessible via the menubar and via keyboard
> > shortcuts. The shortcuts are shown behind the menu entries.
>
> Currently the main model is context sensitive popups (right click).
> There're some things you can't get from them (e.g. Open File), but
> I see no point in duplicating the popup menus from the menu bar.
>
> About everything being accessible via keyboard shortcuts, I don't
> agree. I believe there are simpler ways. For instance if there's a
> shortcut for every popup menu entry, there's a need to remember a lot
> of shortcut/function pairs. Now if there's a shortcut to popup the
> context sensitive menu, and that menu is keyboard operable, IMHO that's
> easier to remember/use.
> If there's a frequently used operation inside a popup, it may have
> its own shortcut.
I think the advantage of a menu bar is that it's easily visible, what functionality
is available. Advanced users will probabely use shortcuts.
But you are right. I forgot about the context menus. The link and image menu
only makes sense as a context menu.
>
> > shortcuts are shown behind the menu entries.
>
> Agreed.
>
> > * All shortcuts are configurable.
>
> Agreed.
>
> >
> > * No more img on/off button. One can use a menubar entry or keyboard
> > shortcut instead.
>
> I prefer the button. It's more visible and gives feedback on its
> current status.
> Firefox has this functionality somewhere, and a few people know
> of it.
Ok.
>
> > * The "Search the Web" button should be just as all the other
> > buttons ("Back", "Forw" ...) and be configurable of course.
>
> Agreed.
> With something like:
> search_url="<title>,<URL>" in dillorc2, with the first
> one being the default for instance.
>
> > Perhaps a single config option like:
> > panel_buttons="back, forw, home, reload, save, stop, book"
>
> I prefer the boolean way (current model).
>
I was looking for a way to make the ordering configurable too.
> > * The "HTML bugs" button in the status bar is ok.
> > It shows the bug-state of the current page.
>
> Agreed!
>
>
> > * "Search the Web" opens the start page of the selected search
> > engine (e.g. google.com) and selects the search text field.
> > I'm not sure about that, but it avoids the dialog window and it makes
> > clear to which search engine the query is sent.
> > The additional page load for the empty search page is only
> > required once - then it's cached.
>
> NO! :-)
>
> I love avoiding the search page. e.g. with google.
>
> ...but, yes, I see there may be cases where the native HTML interface
> is preferred. Maybe a simple flag can help it:
>
> search_url="<title>,<URL>[,LoadPage]"
>
> Thus, with no flag, we get a dialog:
>
> .------------------------------,
> | Search with <title>: |
> | [_________________________] |
> | |
> | [Cancel] [OK] |
> '------------------------------'
>
> and with the "LoadPage" flag, the HTML page.
>
> This can be implemented quickly! ;-)
>
Or a plugin, that presents a HTML page with search forms?
I'm not sure myself :-)
>
> > * In fullscreen mode "Ctrl-l" opens a dialog window again. Any
> > better solution?
>
> If the redraw can be avoided, could be, if not, the dialog may be
> OK. I haven't used this case too much so I don't *feel* the problem.
>
Yes, I was also thinking about reintroducing the dialog in this case.
Cheers,
Johannes
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
16 years, 2 months