Hello, Sorry for the huge mail. :)
# Moving the dns stuff to IO. # Move all the socket stuff into IO.c, the module that wants to handle opening the connection should also close it (all non-internet sockets, like files. Unix sockets may be added to IO.c.). Gzilla had a flat design, we've come a long way to layer dillo and to separate its code in modules.
It's not what you think, what I meant was to move dns.c|h to the IO directory, not to move the code from those files into IO.c, I would never do that. What I want to do is to move the code into the modules where it belongs. I see no reason why the IO module shouldn't handle all the socket related stuff, currently http.c makes a new socket and connects it, then it passes it more or less to the IO module. It seems more logical and modular to me when the IO module does those TCP/IP specific things when http calls IO_new. Let the IO module do the IO, and the http module do the http related things, that's my opinion. I don't see the http module doing anything special with the dns info, so it probably makes more sense to let the IO module use the dns module too. You seperated the code in modules and layers, what I want to do now is to move code to the place it belongs, making Dillo in my opinion more modular, overall simpler and more flexible. Currently this has the effect that the IO modules becomes bigger and more complex, but it also means that the http module will be smaller and simpler, and that it's easier to add more http like modules in the future. What's bad about the current ccc functions? The problem is that currently not all modules can communicate blindly with other modules via ccc functions, because different ccc functions expect different parameters. Also most of the time modules know exactly with which module they talk, they have no choice, otherwise they don't know what parameters to give and expect. Now you use ccc functions like a sort of bad used void pointers: You know what you get, you know what you call, but still tunnel it through a typeless function. You mix a general API with module specific API's, making things only very confusing and unclear. All I want is a clear API. I see how ccc functions are usefull, and what their point is, but that is not my problem with them, the idea of a sort of linked list of functions is nice, but the implementation isn't very well if you ask me. Also the API used internally in Dillo isn't consistent. For example: Why call a_IO_new and not IO_ccc with OpStart? Things are unnecessary complicated and inflexible now. It's not easy to unravel the spaghetti, but it's doable, and when you're done you've a nice clean internal API that makes implementing library plugins a piece of cake.
It serves to isolate the query process from the answer process. Also as dillo uses pipes to talk to itself, it makes sense to have read-only and write-only FDs. Of course it can be merged, but it may be not simple.
With pipes it makes sense yes, but in general all other connections are bidirectional. Dillo uses mostly TCP, then it's one socket, one connection, one fd. And one IOData structure if you ask me. If you use one IOData structure that is also bidirectional, then all you need to do with pipes is to still use two IOData structures, but only for pipes. One IOData structure for each fd makes most sense to me. Connection caching. You say that Dillo has it, but when I open a website, and look with netstat, Dillo has no open connections. Same experience with debug output. Maybe Dillo has it with dpi connections, I don't know, didn't look at that code yet, but in general Dillo has no connection caching, at least not the kind I mean. The one I would want to have is that keeps connections open until the server closes them, or until they time out (I'm not sure if all connections should be cached, or only the one to the last domain/current site).
In the past that approach was used. ~/.dillo ended having a splash file for each release. The point is that what's more memory consuming is the widget tree for rendering, not the source itself.
I do not know (nor want to know ;) how you first implemented it, what I was thinking about is opening by default the about html file. To have something that does exactly the same as now, all you have to do is open by default e.g. /etc/dillo_splash.html. It takes about 5 lines, patch is written within 15 minutes, most work is getting rid of the old code. And instead of keeping that 10K splash info all the time in memory, you now don't use any memory at all for it, except the one to render it, but that's gone after going to another site (if we can tell the cache to not cache it anyway, but that's the same for the current implementation). Putting an about file integral into Dillo, that's what I consider being monolithic. There is nothing wrong with a distributed design, but my problem with you pushing everything into dpi plugins is that most of those things can be done in seperate modules, meaning that they can be library plugins as wel. It becomes scary when a simple "hello" dpi plugin is 150 lines of code, while the whole ssl support to IO.c is about the same (and much less when there is one IOData/fd). Now you get much more code that all does more or less the same, you may have kept the Dillo core clean and mean, but you get a ridiculous complicated and big plugin system, moving most of the code and functionality outside of Dillo (but in the same time making it twice as big). Now it's very tempting to make a dpi library that implements most used functions, as someone already discovered. What's the next step? Moving all the useful code from Dillo to that library so that even more code is shared I guess (and let Dillo use that library too). What you get is a weird attempt to make something that more or less resembles library plugins, but in, if you ask me, a very awkward way. Of course there are plugins that behave more like daemons, like the bookmark plugin, but then make it a real daemon, so that it can be used by even other browsers. With a flexible and clear internal API most plugins can be done with relative small and simple library plugins, and a few can be implemented as real daemons.
# Add ftp support. It has.
Using wget for something as basic as ftp in a plugin isn't something that I would call ftp support. Dillo is not a graphical front end for wget, thus I do not think Dillo has ftp support. Wget has.
(this is old problem of sharing a single resource among several clients).
An old problem that is solved long ago. Just use inter process communication, like file locks (you can unlock you know). Only what you need to add is an extra fstat to see if the file is edited, and if so, reload the cookies. No big deal if you ask me.
Yes I agree with that reusing dillo's http may come handy.
the details of handling the possible errors should be solved by
What your mistake is, in my humble opinion, is that you treat https like a seperate protocol, instead of http over another kind of connection. My view is that http is just http over ssl, and that ssl should be a sort of sub-module of IO (or a module that's only used by IO, like dns would be in my way). If you take a look at my patch, you'll see that the changes in http.c and IO.c are minimal, most of the code is at the bottom of IO.c, it could be easily a seperate file (again, only if there is one IOdata per fd, but then the ssl code will be 50 lines or so). Currently proxy support has more impact on http than https support, and you should treat them in a similar way if you ask me. You don't want a seperate plugin or module for proxy http, why do you want one for https? If you mean with monolithic that it's part of the core code, then yes, my way is monolithic, but it's only very little code, modular, and much less monolithic than an embedded splash page. 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.
Not at all. The openssl api supports error callback functions, so the SSL/TLS support in IO can be minimal, if modules need more control they can use the callback functions. All that is needed is a general behaviour that is sufficient in 90% of the cases, and the current implementation does exactly that. Because modules have access to the SSL structure they can have all control they want, if needed. There are more or less 3 types of errors: 1: Connection related errors. (handshake_failure etc) Not much choice how to handle this, retry or abort (all connection related errors, including ssl related things like unsupported something). 2: Bad use of the API. (illegal_parameter) Should never happen with a good implementation. 3: Certificate related errors. (6 out of the 8 errors you listed) Most certificate related things can be done with openssl callback functions, so it's very seperate of the rest, making it easy to add or change later, or to handle it as module. Maybe there's something needed to give the module a chance to do it's certificate (startup) things and setting up the error handling, but not much. All in all IO doesn't have to worry much about all those SSL errors.
It puzzles me: changing the IO engine,
Only what will chance is that it does more what it should do, handling IO.
integrating parts of the code that were separated on purpose,
That was a misunderstanding, I wouldn't do that, sorry for not being clear enough.
changing the internal API, getting rid of the CCC
The current CCC API is not clear or flexible, nor simple. Maybe a more consistent CCC API is possible, maybe no CCC functions at all, I don't know yet, but I'm not simply getting rid of the CCC.
and porting to FLTK, we'd be talking about another browser.
Well, porting to FLTK, FLTK has similar aims as Dillo (small and fast), so maybe it was best if it was implemented with FLTK in the first place, but it's too late for that now. I would think twice before porting Dillo to FLTK (making sure that FLTK is alive and actively developed is one thing I would do), but GTK 2 is currently just scary, so FLTK as long term option isn't that bad. Getting libraries smaller is always hard, and GTK 2 is 12 mb now? I also saw the benchmarks, all in all not very encouraging. There is also an existing UTF8 Dillo patch, so maybe it's an option to stick with GTK 1 for a while. I didn't make Dillo, nor do I have much GUI programming experience, so I'm the last one you should listen to when it comes to what widget set to use. But from the networking side, FLTK has a perfect API, only a thin layer on top of select/poll, making it possible to easily add, remove and change the poll events on fds. GTK has an undocumented way of removing fds, can only hope it cleans the io channels up too and so on, but it still has no way to change the events on a fd. GTK has a lot bloat in it's io channel implementation (it's bloat when you don't need all it's features). I looked a bit in GTK's online API, and found the "perfect" replacement for io channels, a bunch of GDK functions that do almost exactly what Dillo needs: http://developer.gnome.org/doc/API/gdk/gdk-input.html It gives us almost the same API as FLTK does, but instead of being a thin layer, it's implemented with io channels, so the bloat is still there, but no way around that with GTK (not without very ugly complicated stuff). Also I think that the hairy bug isn't there, nor will we get another by GTK caused hairy bug if Dillo uses this GDK API, because it does what we want and need, without adding extra complexity like io channels (sure, the bug wasn't GTK's fault you can say, but if the API was clear and simpler, it wouldn't happen). Also FLTK uses internally the same select/poll as for our fds, X communicates through unix sockets, so whole FLTK blocks when nothing happens, while it seems that GTK polls 50 times/second for events or something like that. It's just that I prefer FLTK's way of doing some things. :)
Making a web site (or page for it) requires time, if you're willing to do that, go ahead but beware that we do not support unofficial patches so you'd have to answer all the incoming questions too.
Hmm, a web page, mind if I use the code of the splash screen as a basis? I only want to make an installer so that it's easy for people who, for instance, don't know what cvs is, to get a patched Dillo version. The goal is to have some sort of centralized patch place, with patches that work with eachother and are up to date. It requires time, true, but I'm willing to spend time on Dillo. The installer has no priority though, would rather spend my time to unite the IOData structures, switch to the GDK api, and clean up the https patch for now. All the things I want to have different in Dillo I'm willing to change myself. I'm not saying you should change this or that so or so, I ask if you mind if I change or add some things a certain way, and if you agree that it's better that way. Greetings, Indan (I wonder how many people wil read this 13K monster :)
Hi,
Sorry for the huge mail. :)
And most of it is rather interesting but way more than I know about software design and C :-)
# Add ftp support. It has.
Using wget for something as basic as ftp in a plugin isn't something that I would call ftp support. Dillo is not a graphical front end for wget, thus I do not think Dillo has ftp support. Wget has.
I made a prototype ftp plugin that is based on http://nbpfaus.net/~pfau/ftplib/ Did I post this to the list or only to Jorge ?!? Unfortunately, lately I have a hard time dedicating some quiet time to dillo, so it's still sitting there. But since I could do it, then almost anybody can :-)
(this is old problem of sharing a single resource among several clients).
An old problem that is solved long ago. Just use inter process communication, like file locks (you can unlock you know). Only what you need to add is an extra fstat to see if the file is edited, and if so, reload the cookies. No big deal if you ask me.
AFAIR, the problem is that dillo tries to keep cookies in memory and writes them to disk only when absolutely necesarry. It's a privacy issue.
(I wonder how many people wil read this 13K monster :)
Ok, so I went back and read more ;-) But I leave it to the core developers to comment on it. I only found two points I could comment on. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
Hello,
I made a prototype ftp plugin that is based on http://nbpfaus.net/~pfau/ftplib/ Did I post this to the list or only to Jorge ?!?
I'm a from scratch die-hard ;), I would write all the code myself, I already looked at the FTP RFC and it's not too hard I think, especially if you only implement what you need (only passive transfers for instance). You posted it to the list, I remember reading it somewhere. That lib seems interesting though, even if only as reference.
AFAIR, the problem is that dillo tries to keep cookies in memory and writes them to disk only when absolutely necesarry. It's a privacy issue.
No, that's not a problem, cookies that stay all the time in memory don't have to be synchronized, the problem is caused by that few cookies that need to be written to the cookies file, or so I think. Reading and writing to the cookie file everytime another Dillo instance changes it isn't very fast, but it shouldn't happen often, people shouldn't enable cookies for all sites. I use ENABLE_SESSION, but those cookies shouldn't be written to disk. Using file locks is simple to implement, even more so because Dillo already use them. It's possible to have a more complex system that manages that all Dillo instances use the same cookies, even in memory, with shared memory and semaphores, but those few cookies that are explicitly enabled aren't worth all that hassle. Greetings, Indan
On Mon, 10 Nov 2003, Indan Zupancic wrote: [cut - a lot!]
Making a web site (or page for it) requires time, if you're willing to do that, go ahead but beware that we do not support unofficial patches so you'd have to answer all the incoming questions too.
Hmm, a web page, mind if I use the code of the splash screen as a basis? I only want to make an installer so that it's easy for people who, for instance, don't know what cvs is, to get a patched Dillo version. The goal is to have some sort of centralized patch place, with patches that work with eachother and are up to date. It requires time, true, but I'm willing to spend time on Dillo. The installer has no priority though, would rather spend my time to unite the IOData structures, switch to the GDK api, and clean up the https patch for now.
All the things I want to have different in Dillo I'm willing to change myself. I'm not saying you should change this or that so or so, I ask if you mind if I change or add some things a certain way, and if you agree that it's better that way.
Greetings,
Indan
Sorry to interrupt... I'm a keen user of Dillo but no hacker. I'll not comment on all the internals of Dillo since you guys are much more clever on this than me. But, see - the reason why I like Dillo is that it is light and mean - and can be tweaked into something I need. My need is a *light* browser which can be fitted into a thin client but still allow you to read web mail. This requires frame and https support. Other users of Dillo, like PDA users, couldn't care less about frames and https. The key point here is that neither I nor the PDA guys really have anywhere else to go than Dillo. I need to patch up Dillo with both Franks tab/frame patch and Indans https patch. Currently Franks patch is at ver. 14. The latest patch working on the most recent official Dillo release (0.7.3) is - as far as I remember - version 6. Today, when Franks new patch came out, I patched the Dillo cvs version with it. No problem. When I tried to add Indans https patch, it didn't work. Too old. Two weeks ago I tried the same. At that time the problem was the opposite! Honestly, this isn't a good situation. After following the mailing list for a couple of months I understand that the core developers have strong oppinions on the structure of the internals of Dillo. The is probably good since this created Dillo as it is in the first place. But in my humble oppinion either Dillo should release official minor version (0.7.4, 0.7.5 etc) more often so privateers can offer patches against these, or go along with this suggestion of Indans and support a semi-official patch model. The current model will not bring Dillo forward with the necessary speed, I fear. A lot of good ideas need to be tested and eventually absorbed if proven good.
(I wonder how many people wil read this 13K monster :)
I did! And this post even looks short now ;-) Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS
When I tried to add Indans https patch, it didn't work. Too old. Two weeks ago I tried the same. At that time the problem was the opposite!
Plain bad luck, Jorge just changed those files enough, and I was bussy with making a pc stable and upgrading it, all my Dillo files are backuped on another pc now, it's a slight mess. :) Also I want to merge the read/write IOData structures, and change to the GDK API, if Jorge and others agree with that. If that's going to change then updating my https patch now is a waste of time, because relatively much is going to change (the https patch will shrink incredibly :).
But in my humble oppinion either Dillo should release official minor version (0.7.4, 0.7.5 etc) more often so privateers can offer patches against these, or go along with this suggestion of Indans and support a semi-official patch model.
More often is not the point, Dillo is relatively close to 0.80 and far away from 0.73, so this seems to be just an unfortunate time for patches. Normally you should just use the 0.73 patches. There is no 0.73 https patch from me because I'm not happy with the current implementation, caused by all the hassle with keeping the two IOData structures synced and GTK's io channel annoyance. If there are fewer official Dillo versions it's easier to keep all the patches up to date. Actually, all what is needed is a cvs tag for each stable release, and maybe some extra tag for sort of beta versions that can be used for patches if it turns out that the official releases are not often enough for the patches. This way it's clear for the patches what Dillo version to use, so all can be relatively easily kept synchronized (at least for what Dillo version the patches use). Having a central place for all Dillo patches is always useful, because that way it's easier to find and use them for users. Centralised isn't the same as semi-official, it's a united effort of the patch makers. And that means they probably have something betters to do, say, improving their patch and keeping it up to date with cvs. ;) Greetings, Indan P.S. Seems like I just can't write short mails. :(
Indan Zupancic wrote:
Having a central place for all Dillo patches is always useful, because that way it's easier to find and use them for users. Centralised isn't the same as semi-official, it's a united effort of the patch makers. And that means they probably have something betters to do, say, improving their patch and keeping it up to date with cvs. ;)
Another thing we can do is go the 'sylpheed-claws' route: create an extended version of Dillo, which regularly syncs up with Dillo CVS (and, possibly, the other way around). That way it is easier to create and maintain those features which are missing from Dillo. The risk is of course that the extended version starts to divert so far from CVS that it is hard to use it as a base to patch CVS. I've thought about going that way with the tab/frame/keyboard_navigation patch, as it does not get that much exposure currently. I have not done it yet, but given the number of patches which languish because of lack of exposure it is probably a good start. An 'experimental' branch on CVS and the main Dillo site would work as well of course... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
On Tue, 11 Nov 2003, Mike Eriksen wrote:
Sorry to interrupt... I'm a keen user of Dillo but no hacker. I'll not comment on all the internals of Dillo since you guys are much more clever on this than me.
But, see - the reason why I like Dillo is that it is light and mean - and can be tweaked into something I need. My need is a *light* browser which can be fitted into a thin client but still allow you to read web mail. This requires frame and https support. Other users of Dillo, like PDA users, couldn't care less about frames and https.
you can use my patch for 0.7.3 until something better appears... http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz-wtab.diff.bz2 http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html It contains both tabs patch v6 and one https implementation (mine), but you should read sslgw/README to get it work, if you want to use it. Note: When Indian continues to maintain his https patch i'll probably do not bother with mine, lazy as i am... Also the Indian's idea of cleaning up ccc into something more easy to understand is nice (current ccc has at least one bad property - it is _hard_ to understand what goes on in it).
The key point here is that neither I nor the PDA guys really have anywhere else to go than Dillo.
In message <Pine.LNX.4.58.0311111201430.31566@kiku.itsise>, Madis Janson <madis@ats.cyber.ee> writes
you can use my patch for 0.7.3 until something better appears...
http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz-wtab.diff.bz2 http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html
To reiterate It would be _really nice_ if all these links to these very useful patches were findable from the dillo main site :-) -- robert w hall
On Tue, Nov 11, 2003 at 10:37:41AM +0000, robert w hall wrote:
To reiterate It would be _really nice_ if all these links to these very useful patches were findable from the dillo main site :-)
Perhaps some enterprising individual (not me) would be interested in hosting some sort of Dillo Wiki. Any patch authors could then post links on the wiki without having to bother website maintainers... Paul
On Tue, Nov 11, 2003 at 07:20:04AM -0500, Paul Pelzl wrote:
On Tue, Nov 11, 2003 at 10:37:41AM +0000, robert w hall wrote:
To reiterate It would be _really nice_ if all these links to these very useful patches were findable from the dillo main site :-)
Perhaps some enterprising individual (not me) would be interested in hosting some sort of Dillo Wiki. Any patch authors could then post links on the wiki without having to bother website maintainers...
A Wiki could be nice if someone were to set it up (and maintain it). A maintained list of patch sites on www.dillo.org could be nice, again if someone will do the work to keep it from getting stale. But there already already is a user-writable area on www.dillo.org, which supports small modifications -- the bug-track database. That dillo does not support frames is BUG#131, not claimed by anybody. If the owner is prepared to put their address on the web, volunteer for it with "frank@wherever, patch at http://www.geocities.com/ikbenfrank/" as the comment. That dillo does not support https: URLs is BUG#223, although there's an undated indication that someone is working on that. Possibly add "patch at http://www.xs4all.nl/~dorinek/dillo/" to that entry, after checking with the current volunteer. (Or, maybe, log a new https:// bug and volunteer for that with the details. Although deliberately duplicating bugs might be considered impolite.) Keyboard navigation is BUG#230. Are there any patches floating about for features not in the bug-track database? Keep the URLs short (there's only 64 chars to play with, I believe) and people looking for fixes should be able to find them. Does that help the problem at all? All the best, f -- Francis Daly francis@daoine.org
Hi there,
On Tue, Nov 11, 2003 at 07:20:04AM -0500, Paul Pelzl wrote:
On Tue, Nov 11, 2003 at 10:37:41AM +0000, robert w hall wrote:
To reiterate It would be _really nice_ if all these links to these very useful patches were findable from the dillo main site :-)
Perhaps some enterprising individual (not me) would be interested in hosting some sort of Dillo Wiki. Any patch authors could then post links on the wiki without having to bother website maintainers...
A Wiki could be nice if someone were to set it up (and maintain it).
A maintained list of patch sites on www.dillo.org could be nice, again if someone will do the work to keep it from getting stale.
I've been hearing complaints about unnoficial patches for years. It takes time an dedication to make such a compilation, to answer the incoming messages, and to keep them up to date. Nobody has volunteered to do that in a stable basis, so please allow me to remember that the current CVS is what we, the core and steady developers, have taken the time and effort to integrate (review the ChangeLog it's a quite large list). So if somebody wants to do the same with unofficial patches, _that doesn't belong to the official site_. I'd gladly provide a link to it, but beware that this new site's maintainers must take care of all of the incoming messages related to unofficial patches, and all the associated burdens.
But there already already is a user-writable area on www.dillo.org, which supports small modifications -- the bug-track database.
Please don't (for above mentioned reasons). Sincerely Jorge.-
At 04:20 AM 11/11/2003, Paul Pelzl wrote:
Perhaps some enterprising individual (not me) would be interested in hosting some sort of Dillo Wiki. Any patch authors could then post links on the wiki without having to bother website maintainers...
I might be able to set something up on my site. Can anyone recommend some good Wiki software? The lists at Freshmeat.net and Wikipedia are extremely long, and while I'm inclined to look at MediaWiki, it looks like it would be overkill for this purpose. Kelson Vibber www.hyperborea.org
In message <6.0.0.22.0.20031111113824.0261c2e8@mail.speed.net>, Kelson Vibber <kelson@pobox.com> writes
I might be able to set something up on my site. Can anyone recommend some good Wiki software? The lists at Freshmeat.net and Wikipedia are extremely long, and while I'm inclined to look at MediaWiki, it looks like it would be overkill for this purpose.
sounds a very welcome offer and well worth a try thank you Bob -- robert w hall
Kelson Vibber wrote:
At 04:20 AM 11/11/2003, Paul Pelzl wrote:
Perhaps some enterprising individual (not me) would be interested in hosting some sort of Dillo Wiki. Any patch authors could then post links on the wiki without having to bother website maintainers...
I might be able to set something up on my site. Can anyone recommend some good Wiki software? The lists at Freshmeat.net and Wikipedia are extremely long, and while I'm inclined to look at MediaWiki, it looks like it would be overkill for this purpose.
I have used twiki (www.twiki.org) with great success. WIsh I had broadband here in Sweden, I would be running it now... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Note: When Indian continues to maintain his https patch i'll probably do not bother with mine, lazy as i am... Also the Indian's idea of cleaning up ccc into something more easy to understand is nice (current ccc has at least one bad property - it is _hard_ to understand what goes on in it).
It is my intention to keep my https up to date, it will be in a couple of days. I'm more or less waiting till Jorge tells me that I may go ahead with writing a patch that does that IOData and GDK stuff, or that he wants to keep it as it is now. That way it's clear for me what I can do, and how the more final version of my https patch should look like. I started documenting how the CCC functions are used currently in Dillo. After having it clear what happens now it's easier to see how to improve it, and what's wrong with the existing implementation. I do not know how hard it is to manage an experimental CVS branch, it has advantages and disadvantages. One pro is that the patches always work with eachother, because they use the same code, but that also means that the patches won't work seperately, that is, there is just an extended Dillo version, and no real patches anymore. It is very good to work with a stable code base, because then it's clear that all the encountered bugs are caused by your code, and not by someone else's code. Also it's useful when the base code doesn't change that much, especially when the patch is young. It is easier to keep the code up to date when it has it's own cvs branch, but on the other hand it could also mean that if someone drops his code and stops working on it, that someone else need to keep it up to date. Altogether quite risky. Of course everything is much simpler when only a few people use the alternative branch, it shouldn't be a dump place for never updated patches (tiny ones are ok of course). I think it will be only succesful when the branch is used only for things that have a chance to come in the official Dillo, as a sort of testing and developing place. Otherwise it will be very hard to keep it in sync with the official Dillo version, and the changes will only become greater after a while. Greetings, Indan
Hello, I updated the https patch, it should work with the current cvs now. I didn't change anything, it's no real update, only to keep the impatient happy. ;) It's a quick fix, real update will come later. Greetings, Indan
* Indan Zupancic <indan@nul.nu> [11-11-03 19:28]:
I updated the https patch, it should work with the current cvs now. I didn't change anything, it's no real update, only to keep the impatient happy. ;)
It's a quick fix, real update will come later.
Thanks, but: pat@wahoo:/dillo.cvs.1110> patch -p1 <dillo-ssl.diff patching file configure.in Hunk #1 succeeded at 26 with fuzz 2 (offset 2 lines). Hunk #2 succeeded at 177 (offset 8 lines). Hunk #3 succeeded at 225 (offset 22 lines). patching file src/IO/IO.c patching file src/IO/IO.h patching file src/IO/Url.c patching file src/IO/http.c patching file src/capi.c Hunk #1 FAILED at 255. 1 out of 1 hunk FAILED -- saving rejects to file src/capi.c.rej pat@wahoo:/dillo.cvs.1110> cat src/capi.c.rej *************** *** 255,266 **** a_Capi_dpi_send_cmd(web, web->bw, cmd, "ftp", 1); g_free(cmd); } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->bw, cmd, "https", 1); g_free(cmd); } else { return a_Cache_open_url(web, Call, CbData); --- 255,268 ---- a_Capi_dpi_send_cmd(web, web->bw, cmd, "ftp", 1); g_free(cmd); + #ifndef HTTPS } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->bw, cmd, "https", 1); g_free(cmd); + #endif } else { return a_Cache_open_url(web, Call, CbData); it fixes three of the four failures I rec'd. ??? tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
* Patrick Shanahan <paka@MyRealBox.com> [11-11-03 21:56]:
* Indan Zupancic <indan@nul.nu> [11-11-03 19:28]:
I updated the https patch, it should work with the current cvs now. I didn't change anything, it's no real update, only to keep the impatient happy. ;)
It's a quick fix, real update will come later.
Thanks, but:
pat@wahoo:/dillo.cvs.1110> patch -p1 <dillo-ssl.diff patching file configure.in Hunk #1 succeeded at 26 with fuzz 2 (offset 2 lines). Hunk #2 succeeded at 177 (offset 8 lines). Hunk #3 succeeded at 225 (offset 22 lines). patching file src/IO/IO.c patching file src/IO/IO.h patching file src/IO/Url.c patching file src/IO/http.c patching file src/capi.c Hunk #1 FAILED at 255. 1 out of 1 hunk FAILED -- saving rejects to file src/capi.c.rej
pat@wahoo:/dillo.cvs.1110> cat src/capi.c.rej *************** *** 255,266 **** a_Capi_dpi_send_cmd(web, web->bw, cmd, "ftp", 1); g_free(cmd);
} else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->bw, cmd, "https", 1); g_free(cmd);
} else { return a_Cache_open_url(web, Call, CbData); --- 255,268 ---- a_Capi_dpi_send_cmd(web, web->bw, cmd, "ftp", 1); g_free(cmd);
+ #ifndef HTTPS } else if (g_strncasecmp(url_str, "https:/", 7) == 0 && !Call && (a_Capi_url_read(web->url, &sz) == NULL || (URL_FLAGS(web->url) & URL_E2EReload)) ) { cmd = g_strdup_printf("<dpi cmd='open_url' url='%s'>", url_str); a_Capi_dpi_send_cmd(web, web->bw, cmd, "https", 1); g_free(cmd); + #endif
} else { return a_Cache_open_url(web, Call, CbData);
it fixes three of the four failures I rec'd. ???
Ok, I'm knock-kneed, back-handed and generally challenged. The ssl patch will work against the cvs from 11-11, but not from 11-10 (thats month-day) and the tabs patch will work against 11-10 and not 11-11. Kind of a quandary, eh.... -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
Patrick Shanahan wrote:
Ok, I'm knock-kneed, back-handed and generally challenged. The ssl
patch will work against the cvs from 11-11, but not from 11-10 (thats month-day) and the tabs patch will work against 11-10 and not 11-11.
Kind of a quandary, eh....
Sigh... I'll put out a new version of my patches RSN.. I have also found a small error in Jorge's patch to url.h, so I'll try to get that committed to CVS before I produce my patch set - otherwise you'll get yet another reject once CVS is updated. Jorge, please apply the attached patch to CVS ASAP, so it does not cause rejects with my forthcoming patches... It fixes the error in the macro definition for URL_ILLEGAL_CHARS(u) and adds the missing URL_ILLEGAL_CHARS_(u). Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ] --- dillo/src/url.h 2003-11-11 21:45:02.153339032 +0100 +++ dillo_patched/src/url.h 2003-11-12 08:16:28.038808992 +0100 @@ -57,7 +57,7 @@ #define URL_ALT_(u) u->alt #define URL_POS_(u) u->scrolling_position #define URL_STR_(u) a_Url_str(u) -#define URL_ILLEGAL_CHARS(u) url->illegal_chars +#define URL_ILLEGAL_CHARS_(u) url->illegal_chars /* * Access methods that always return a string: @@ -77,7 +77,7 @@ #define URL_ALT(u) NPTR2STR(URL_ALT_(u)) #define URL_POS(u) URL_POS_(u) #define URL_STR(u) NPTR2STR(URL_STR_(u)) - +#define URL_ILLEGAL_CHARS(u) NPTR2STR(URL_ILLEGAL_CHARS_(u)) /* URL-camp compare methods */
patch will work against the cvs from 11-11, but not from 11-10 (thats month-day) and the tabs patch will work against 11-10 and not 11-11.
Kind of a quandary, eh....
The joy of making patches against the CVS version... If the code would be in CVS, then it would stay automatically up to date. Normally, all patches should be made against some logical cvs tag, say, a release, but if the patches are still in development it's logical the maker want them to work with the current cvs version. Personally I'm going a bit crazy because of all those Dillo versions on my hd, one original cvs version, one I work on, one clean one to test if the patches really work, then two fake Dillo directories with symlinks to all the original files, so that I can do "diff -pur" and keep unwanted noise out of the patch, keeping it small and simple. Then I moved all those directories to another pc because I wanted to upgrade my 233 Mhz pc, someone gave me a pentum 3 800 + mobo, one of them more or less broken, whole pc very unstable. Caused major filesystem corruption when I tried it out, got it stable with underclocking the cpu to 700 Mhz, but still can't compile because I suddenly miss some header files. No big deal, I backuped everything, and wanted to switch to Slackware anyway, but still means I have to do all the Dillo stuff via ssh on the other pc, until I have everything back on track again. Anyway, the point was, Frank, you got some tips how to handle all those patches? My current system works fine, but I need yet another directory with Dillo source if I want to make or use another patch. Greetings, Indan
Indan Zupancic wrote:
Anyway, the point was, Frank, you got some tips how to handle all those patches? My current system works fine, but I need yet another directory with Dillo source if I want to make or use another patch.
I've made some scripts which create a temporary copy of the dillo CVS dir and the patched dir, remove all unwanted crud from the patched dir, do the diff and generate some statistics. I can send them if you want. Of course this still leaves the issues with patch makers constantly being out of sync with eachother, and each patch being broken by updates to CVS shortly after the patch was posted. More on that later... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
I've made some scripts which create a temporary copy of the dillo CVS dir and the patched dir, remove all unwanted crud from the patched dir, do the diff and generate some statistics. I can send them if you want.
Hm, a script, didn't thought about that. No need to send them though, can make my own if I need any.
Of course this still leaves the issues with patch makers constantly being out of sync with eachother, and each patch being broken by updates to CVS shortly after the patch was posted. More on that later...
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS. Greetings, Indan
Indan Zupancic wrote:
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS.
I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea. As I do not yet have a server here in Sweden (damn broadband which is not here, but everywhere else...) I can not host this, someone with the resources and time care to chime in? Of course there is always Savannah (http://savannah.gnu.org), Sourceforge, etc. BTW, I also double as a software evaluator for the GNU project (Even though I've not done many evaluations lately for lack of time), and would be more than happy to get Dillo listed as a GNU project. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
On Thu, 13 Nov 2003 07:59:50 +0100 Frank de Lange <frank@unternet.org> wrote:
Indan Zupancic wrote:
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS.
I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea. As I do not yet have a server here in Sweden (damn broadband which is not here, but everywhere else...) I can not host this, someone with the resources and time care to chime in?
Of course there is always Savannah (http://savannah.gnu.org), Sourceforge, etc.
erm... or http://auriga.wearlab.de/ ? ;)
Cheers//Frank
Greetings, Thorben
On Thu, Nov 13, 2003 at 09:50:29AM +0100, Thorben Thuermer wrote:
On Thu, 13 Nov 2003 07:59:50 +0100 Frank de Lange <frank@unternet.org> wrote:
Indan Zupancic wrote:
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard),
<snip>
erm... or http://auriga.wearlab.de/ ? ;)
Or while at it, use indeed the branch mechanism. In the documentation it does not look that much different from current diff-ing. Furthermore, CVS can be configured (with add-ons) to allow certain comittors only comit into certain branches. This is handled via comittinfo and cvs_acls. cvs_acls is a perl script that is at least in the source tar ball of cvs in the contrib section. Most installations of cvs keep it somewhere ( .../share/.../cvs/.../contrib/ ) If ypu should not have a local copy, check http://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in where it is documented in detail how to restrict users to branches. That way, Jorge and Sebastian keep control over the main branch as it is right now, but dedicated branchers could have their repository in the same place. And users simply need to check out these experimental branches. The branchesr only need to marge from current regularly. Of course, I don't know how wearlab has organized their CVS setup and if that would be acceptable. Also, I hope that Jorge or Sebastian read that far down in the thread ;-) ... Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea.
I'm starting to doubt the whole idea, how nice it may be: Are there any other active patch makers out there except us? If not, then is it worth all the trouble? For me it's very easy to keep my https patch in sync with your tabs+frames patch, I'll just sync with CVS when you have a new version, and then attach your version number to the filename, so that it's clear which patches are compatible with eachother. Of course doing the same with other patches won't be as easy, because they may conflict, something that's unlikely with the https patch and frames+tabs patch.
BTW, I also double as a software evaluator for the GNU project (Even though I've not done many evaluations lately for lack of time), and would be more than happy to get Dillo listed as a GNU project.
What are the advantages of being a GNU project? Greetings, Indan
Indan Zupancic wrote:
I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea.
I'm starting to doubt the whole idea, how nice it may be: Are there any other active patch makers out there except us?
If there are, they're hiding in the woodwork. However, this is partly caused by the current way patches are handled. Dillo is not the most patch-friendly project I know of.
If not, then is it worth all the trouble? For me it's very easy to keep my https patch in sync with your tabs+frames patch, I'll just sync with CVS when you have a new version, and then attach your version number to the filename, so that it's clear which patches are compatible with eachother. Of course doing the same with other patches won't be as easy, because they may conflict, something that's unlikely with the https patch and frames+tabs patch.
But that means you are dependent on my quirky release schedule... Something you might not like. There can be weeks, but also days between paches. And I do not always keep up to date with the CVS version du jour. But no, I do not know if it is worth the trouble to set up an Arch/Subversion server for this. Unless...
What are the advantages of being a GNU project?
Exposure, mindshare. 'Everybody knows GNU'. Continuity of maintenance, sort of. Hosting at Savannah (also open to non-GNU projects). No Arch yet, but that might change... Anyway, it is not ours to decide for Dillo to apply to become a GNU project. Jorge, have you thought about this possibility? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach:
I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea.
I'm starting to doubt the whole idea, how nice it may be: Are there any other active patch makers out there except us?
I'm working on JavaScript support for dillo using the SpiderMonkey C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ Code as part of the html-file can already be executed. <script>...</script>, window.*(), window.status, location, history, href="javascript:.." do work. The patch is not yet stable/clean enough to post it here and it lacks a lot. Currently I try to clean it up and get the focus set on google. I thought about a patch on top of Frank's patch as I'm using this every day but this wouldn't make things easier. I know most people here have low-end machines and there is probably no interest in JavaScript support in the main branch. Greets, Stephan
On Thu, Nov 13, 2003 at 04:40:35PM +0100, Stephan Goetter wrote:
Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach:
I think something like Arch or Subversion, with an accompanying Wiki for developers and users to converse (and converge) is a good idea.
I'm starting to doubt the whole idea, how nice it may be: Are there any other active patch makers out there except us?
I'm working on JavaScript support for dillo using the SpiderMonkey C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/
At some point I was thinking (or rather fanatsising :-) ...) about using http://www.bbassett.net/njs/ as a Javascript Interpreter. (That was when I first understood plugins and played with them.)
The patch is not yet stable/clean enough to post it here and it lacks a lot. Currently I try to clean it up and get the focus set on google.
Google uses Javascript ?
I know most people here have low-end machines and there is probably no interest in JavaScript support in the main branch.
IMHO it could be useful to have an extremely light implementation. Only the OnClick, OnSUbmit things. I read on the specs etc., understood only a portion and probably remember only a tiny fraction now :-). But I remember, that it may make sense to only implement a handful of Javascriopt things (as you see, I even forgot the terminology), It may still be compaitible with dillo's design goals. I was mainly thinking of the sites that use Javascript to pop up new windows on clicking some links - which could just as easily be implemented in HTML. I.e. the ones that don't know the difference between Javascript and HTML. Also, the OnSUbmit thing seems to be useful for checking form values before submissions. However, all in all, I use dillo because it does NOT support Javascript and let the browser invade my desktop :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
On Thu, Nov 13, 2003 at 02:46:56AM +0100, Indan Zupancic wrote:
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS.
The best way to handle that with Arch is to have a "CVS gateway" branch that contains only unmodified CVS sources. Other branches (https, tab/frame, etc.) would be tags ("continuations") of the CVS gateway, which would make it relatively easy to merge in patches from CVS. Of course, the "merge in" is where work is sometimes involved, but I don't know of any general solution to that problem. Paul
How about considering subversion ? ( www.tigris.org ). I have been using it at work for about a year with really good results. It can really do branches and such, also handles directories in a sane way. / regards, LArs Segerlund. On Thu, 13 Nov 2003 02:46:56 +0100 (CET) "Indan Zupancic" <indan@nul.nu> wrote:
I've made some scripts which create a temporary copy of the dillo CVS dir and the patched dir, remove all unwanted crud from the patched dir, do the diff and generate some statistics. I can send them if you want.
Hm, a script, didn't thought about that. No need to send them though, can make my own if I need any.
Of course this still leaves the issues with patch makers constantly being out of sync with eachother, and each patch being broken by updates to CVS shortly after the patch was posted. More on that later...
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS.
Greetings,
Indan
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Subversion is certainly "a compelling replacement for CVS" (to use the words of the SVN developers), but it lacks proper support for distributed repositories. I think this feature is ideal for Free software projects, as it makes it easy for developers to make contributions without having to worry about who has write access at a central repository. Paul On Fri, Nov 14, 2003 at 08:14:45AM +0100, Lars Segerlund wrote:
How about considering subversion ? ( www.tigris.org ).
I have been using it at work for about a year with really good results. It can really do branches and such, also handles directories in a sane way.
/ regards, LArs Segerlund.
On Thu, 13 Nov 2003 02:46:56 +0100 (CET) "Indan Zupancic" <indan@nul.nu> wrote:
I've made some scripts which create a temporary copy of the dillo CVS dir and the patched dir, remove all unwanted crud from the patched dir, do the diff and generate some statistics. I can send them if you want.
Hm, a script, didn't thought about that. No need to send them though, can make my own if I need any.
Of course this still leaves the issues with patch makers constantly being out of sync with eachother, and each patch being broken by updates to CVS shortly after the patch was posted. More on that later...
What about making a seperate Dillo repository, but instead of using CVS that is too centralized and can't handle branches very well (or so I heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much easier to manage all the patches, with one branch for each "patch" (one branch for https, one for tab+frames, etc). The hardest part should be to keep our main branch in sync with Dillo's CVS.
Greetings,
Indan
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Hello, I looked a bit more into it, and found several revision systems, one of them Subversion. The most important part is how good the program is in merging branches, because that's the most work. Normal diff can't handle it very well, CVS makes it only easier to fix it manually from what I saw of it, so that is what the main advantages of Subversion and Arch should be, easy merging. After reading some docs it seems that Arch is harder to setup and handle, but probably better, and Subversion much easier to use, but not really distributed. Several sites said that Bitkeeper is the best, only it has a not too nice license and isn't open source. I think it's time to find other patch makers, and see how far we can come with plain diffs and CVS first. Using Arch would probably make it easier to handle multiple branches, but may also scare away potential patch makers (meaning that they probably will use diffs and that someone else must apply them to an Arch branch). Subversion has the advantage that it resembles CVS much more, so it's easier to start with. Greetings, Indan ------------------------------------------------------------------ HTTPS patch: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz ------------------------------------------------------------------
Hello, I made a version of my https patch which works with Frank's tabs patch, version 14 I think, there was one silly reject. I also made a simple (unfinished) script to get a patched Dillo version from CVS, edit it for your needs: ------- script ------- #!/bin/sh CFLAGS="-O2 -s -pipe" mkdir Dillo-patched cd Dillo-patched echo "Getting Dillo source..." cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co -D "11/10/03" dillo echo "Getting patches..." wget "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" wget "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" cd dillo echo "Applying tabs patch..." zcat ../dillo-20031110-tabs.patch | patch -p1 echo "Applying https patch..." zcat ../dillo-20031110-https.patch | patch -p1 ./autogen.sh echo "Running configure..." CFLAGS=$CFLAGS ./configure #echo "Compiling patched Dillo..." #make #echo "Install patched Dillo?" #su #make install #exit #cd ../../ #rm -rf Dillo-patched ------- end script ------- Greetings, Indan
On Friday November 14 at 03:35pm Indan Zupancic <indan@nul.nu> wrote:
echo "Getting patches..." wget "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" wget "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" cd dillo
echo "Applying tabs patch..." zcat ../dillo-20031110-tabs.patch | patch -p1 echo "Applying https patch..." zcat ../dillo-20031110-https.patch | patch -p1
Should that be: zcat ../dillo-20031110-tabs.patch.gz | patch -p1 ^^^^^ -- -johann koenig Today is Pungenday, the 26th day of The Aftermath in the YOLD 3169 My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp
Should that be: zcat ../dillo-20031110-tabs.patch.gz | patch -p1
Oops, yes, of course. As I said, edit it for your needs. ;) Seems like I copied the wrong (untested) version, I mean, I tested the thing and it worked, so didn't expect that I would send the not working version, silly me. Well, jet another reason to not send emails too hasty. Thanks for pointing it out. Indan
I friend of mine ran into trouble with the lovely combined frames/tabs/https patch and gcc 2.9x. It turned out to be an issue already discussed earlier for the stand-alone version of the https patch concerning a small difference between gcc 2.9x and 3.x, but possibly some people did't catch this original discussion. The cure goes like this: At line 842 in dillo/src/IO/IO.c change FROM: ssize_t St = SSL_read.... TO: ssize_t St; St = SSL_read... The same goes for line 872. I had the impression this already was fixed by Indan, but apparently not. Best regards, Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS
ssize_t St = SSL_read....
TO:
ssize_t St; St = SSL_read...
The real problem is the "errno = 0" before the St. I handled it as a declaration, while it obviously isn't one. Just realized that after Paul Pelzl pointed it out (say thanks to Paul, he also sent a patch that adds proper openssl autoconfiguration :). I edited the patches, should be fixed now. New https version soon (after making sure the changes I made are worth it). Greetings, Indan
Thank you, Indan! This works great! I hope you will consider to match your HTTPS patch against Franks frames/tab patch once in a while. It makes life so much easier for amatuers like myself. If you guys manage to get the branching to work, this will of course be solved this way. A short note to people trying to compile on Red Hat 9.0: Add: EXPORT CPPFLAGS=-I/usr/kerberos/include in front of "./configure" (and don't forget to to change the zcat lines from "...patch" to "...patch.gz" as pointed out elsewhere) Mike On Fri, 14 Nov 2003, Indan Zupancic wrote:
Hello,
I made a version of my https patch which works with Frank's tabs patch, version 14 I think, there was one silly reject. I also made a simple (unfinished) script to get a patched Dillo version from CVS, edit it for your needs:
------- script ------- #!/bin/sh
CFLAGS="-O2 -s -pipe"
mkdir Dillo-patched cd Dillo-patched echo "Getting Dillo source..." cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co -D "11/10/03" dillo
echo "Getting patches..." wget "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" wget "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" cd dillo
echo "Applying tabs patch..." zcat ../dillo-20031110-tabs.patch | patch -p1 echo "Applying https patch..." zcat ../dillo-20031110-https.patch | patch -p1
./autogen.sh echo "Running configure..." CFLAGS=$CFLAGS ./configure
#echo "Compiling patched Dillo..." #make #echo "Install patched Dillo?" #su #make install #exit #cd ../../ #rm -rf Dillo-patched ------- end script -------
Greetings,
Indan
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
-- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS
participants (15)
-
Andreas Schweitzer -
Francis Daly -
Frank de Lange -
Indan Zupancic -
Johann Koenig -
Jorge Arellano Cid -
Kelson Vibber -
Lars Segerlund -
Madis Janson -
Mike Eriksen -
Patrick Shanahan -
Paul Pelzl -
robert w hall -
Stephan Goetter -
Thorben Thuermer