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

[Dillo-dev]about java script support
by Thierry Zhong 12 Feb '04

12 Feb '04

Hi,all Does dillo support java script now? Or is there any work on this feature? Thanks and Best Regards! Thierry

2 1

[Dillo-dev]dillo-0.8.0 release
by Jorge Arellano Cid 09 Feb '04

09 Feb '04

Hi, Finally it's done. dillo-0.8.0 was released today! (Already submitted to freshmeat and expecting for display). Enjoy Jorge.-

1 0

[Dillo-dev]dillo-0.8.0-rc1.tar.bz2
by Jorge Arellano Cid 09 Feb '04

09 Feb '04

Hi, The new 0.8.0-rc1 tarball is ready for download! It is at: http://www.dillo.org/test/dillo-0.8.0-rc1.tar.bz2 Its version string is "0.8.0" instead of "0.8.0-rc1"; to ease the labor of packagers. Unless a problem is reported today, the release will be made tomorrow. Kelson, Phil: I'd wish I could have given you more time for making the packages, but I'm leaving the city tomorrow for a week off! :-) Enjoy Jorge.-

2 1

[Dillo-dev]dillo 0.8.0-rc1 on aix
by Riccardo 08 Feb '04

08 Feb '04

Hello, 0.8.0-rc1 still segfaults with an illegal instruction on AIX, I have done howewer a clean build from the tarball and logged the build process, maybe some of the warnings could be significative. Since it is quite small I just attach it here. -Ric

1 0

[Dillo-dev]AIX problems
by Riccardo 08 Feb '04

08 Feb '04

Hello, since upgrading to 1.2.10 did not help, I pathed manually every file including gtk.h by doing #undef func_data before. - I notice I get 'stcasecmp' implicit declaration warning. - the vsdnprintf was already reported and shouldn't be a matter. at the final linking inside "src" I get errors about duplicate symbols (.strcmp, strcmp, .pov) This time I got the WAIT_ANY error on aix too (I wonder why I didn't get it last time!, maybe because I am using gnu-make ?) and subsituted it with -1. Compile ends. As the last time dillo crashes with an illegal instruction and GDB doesn't return me a useful backtrace. I am quite clueless. Can I compile dillo with debug? -Ric

2 5

[Dillo-dev]Last fixes to dpi...
by Jorge Arellano Cid 06 Feb '04

06 Feb '04

Hi there! The last fixes to the dpi framework were just commited: <q> + Added install-dpi-local; a script to ease non-system-wide installation of the dpi framework. + Fixed dpid to work correctly with a dpi intallation inside the user's account. + Updated several docs with regard to dpi. </q> I'll chase a minor bug now... Hopefully tomorrow there'll be a dillo-0.8.0-rc1 tarball. Cheers Jorge.-

1 0

[Dillo-dev]RPM question, and how close is 0.8.0?
by Kelson Vibber 05 Feb '04

05 Feb '04

At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > I'll start working on it after the 0.8.0 release. Any idea how soon that's coming? I've started making the necessary changes for the RPM spec based on the current CVS version. With luck I'll be able to start building as soon as the tarball is ready. I've posted some test RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's interested. Question: I noticed that several of the included DPIs (https, ftp, download) require wget. However, the main browser does not require wget. That leads to several choices as far as RPM dependencies go: 1. Include all DPIs in the dillo package. Don't require wget. 2. Include all DPIs in the dillo package. Do require wget. 3. Separate the FTP, HTTPS, and download DPIs into a separate package (something like "dillo-protocols") and set that package to require wget. Advantages: #1: Simple installation, most linux distros probably already include wget #2: Simple installation, lets you know about wget if you haven't installed it already. #3: If you don't want wget, you're not forced to install it. If you want the plugin, you're told wget is needed. Problems: #1: If you don't have wget, installing won't tell you that you need it. #2: If you don't want to use those DPIs and you don't want wget, you need to install it anyway. #3: Installing is more complicated, because you have to download and upgrade two RPMs. I don't think #1 is really an option, because it means people can install dillo via RPM and not everything will work. I'm inclined to choose #2 over #3, just because of the simplicity. If someone just wants to install Dillo, they already have to look through a list of about 10 different RPMs for the right system, and sometimes people miss the one they need. I occasionally get requests to add an RPM for a system that's already on the list. On the other hand, some people might consider wget to be unnecessary if they're not going to be using those DPIs. Anyway, has anyone got any thoughts on this issue? Kelson Vibber www.hyperborea.org

2 2

[Dillo-dev]Bookmarks shortcut
by Jorge Arellano Cid 03 Feb '04

03 Feb '04

Hi, I was updating the help page for dillo, and when making a keyboard shortcuts table, just realized that Alt-B for bookmarks didn't belong anymore so I replaced it with the much more orthogonal Ctrl-B. Just visit the new help page to see. BTW, is anyone using the alternative ";" for bookmarks? I very seldom use it, but rely heavily on "." and ",". Cheers Jorge.-

1 0

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

[Dillo-dev]Looking inside the cache
by Jorge Arellano Cid 03 Feb '04

03 Feb '04

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.

1 0