Hi,

Can someone tell me where to download a source with the https, tab patches without having to track down what and or where to patch? Or send me a copy:) thanks

Currently I have a sort of installer that downloads Dillo, the tabs and https patches, and applies them, Can get it from: http://www.xs4all.nl/~dorinek/dillo/install-dillo.sh But it isn't finished yet, nor up to date (Frank has a newer tabs+frames patch). I have a better installer, but I need to get my https patch working first. It stopped working after I changed it a bit :(. There is a weird bug that I can't seem to find, will hopefully fix it today and then update my https patch and the installer. Greetings, Indan

* Indan Zupancic <indan@nul.nu> [11-27-03 13:42]: I'm not qualified to comment about the part snipped...

------

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.

I would appreciate an updated version of the installer. Thankyou for your contributions. Please reconsider. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

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@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@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Hi, To clear up some things to avoid misunderstandings: I will continue keeping the https patch up to date, no matter what else I'll do. As there seems to be enough demand, I will update the installer once a while too.

Sometimes, it took quite some time before Jorge looked at the patches and fixed or accepted (or rejected) them.

I had zero feedback the last 3 weeks, not very motivating. Merely a short email to say that it will be looked at or that it has no priority would be appreciated, I mean, _any_ feedback is. Now it's just a black hole where you pour patches into. Don't forget that it's their program you spend time writing a patch for, but currently it feels like it's a privilege to have your patch integreted in Dillo, even expecting some feedback is asked too much for. May I come to the conclusion that I should spend my time on something else instead of wasting it on Dillo? If they aren't willing to spend 10 minutes writing a short email, why should I spend hours or even days writing and testing some Dillo patch? I don't expect the Dillo developers to just integrate my https patch or so, I wouldn't either without a lot testing and making sure it's stable, but I would expect that they give some feedback about it, I mean, it's their program, they wrote it, so I would expect that they know the code better, so could give good advice about pitfals etc. Or just simply say "no, we don't like your approach, let us keep using wget for https". But for the IO.c patch it's a different case, all it is is a cleanup of their code, naive as I am, I would expected them to want cleaner code, even if it's a small step like I made with the patch.

Anyways, that's how it works here. I got used to it.

Working with one feedback per month is impossible if you want to do major IO cleanups as I want.

However, the core developers probably need to read all mails and keep track with a whole lot more patches - therefore, even they may miss one or two patches/suggestions.

Whole lot more patches? Looking at the CVS activity then I'm not too sure. Also there is a reasonable amount of old patches for Dillo already: multiple https implementations (I only found the last one when I started on mine), UTF8 support, server/client mode, and other I can't remember/didn't found. And looking at the mailing list, they didn't get much feedback either. All those people hooked off as far as I can tell, except Frank.

So, please stay with the project ... hmmm ... some semi-serious suggestion ;-) : do some christmas shopping, enjoy the holidays and wait for the feedback from the developers ...:-)

Christmas shopping? Need money for that I suppose. Enjoy the holidays? Have no job, so it's always holiday for me ;-). And don't know where you live, but christmas is just a commercial paradise here.

However, overall, I like the dpi idea. There are certain advantages:

As with many things, the idea is good, the implementating isn't, IMHO.

- For me, it makes it rather easy to contribute, since I need to only write a program and not to dig through dillo's code (if only I did write more than my simplistic finger plugin ;-) ...)

True, but if I look at the default plugins they're not as easy to make as it should be.

- The concept of extra processes instead of extra code has advantages : - with the download plugin being a seperate process you can even log out of X while the download continues (e.g. over night on dial-up).

That is true. I don't know if you noticed, but if you want to use the current download plugin, you need to start up 3 processes... First, the dpid, then the download dpi, which in turn starts wget. I'm so naive to think it could be only wget, with a simple "handle this protocol with this program with this parameters in this way" system. This way you could also startup your favourite email program when encountering mailto:, to give just one example. Don't forget that there is specific code in Dillo to handle certain plugins like the bookmark and download plugins. The plugins aren't really standalone. Sure, it's not finished yet, but the current dpi system can't solve that problem. What I would do is make a clear library plugin api, then you can implement the download and bookmark GUI in a library, and let the library start up wget. You can even implement a library plugin that handels the dpi plugins, instead of adding the code to Dillo's core as now happened (I mean moving the dpi code into a library plugin). This way you can have relative simple and small library plugins that don't do much, which let external programs like wget do the real work. Or add the features directly in the library plugin, whatever you want.

- the bookmark plugin allows for a real bookark server ! This is something I am contemplating about : wouldn't it be cool if you could access the same bookamrks from different machines via a sophisticated bookmark server ?

No, it doesn't. Not with the current dpi system anyway. As I said in an earlier email, the bookmark plugin should probably be a real, standalone daemon, so that it can also be used with other browser, from different pc's. It can even be hosted by some site, so that wherever you go, you can get your bookmarks :). Of course Dillo could have special support for it, so that it's easier to add bookmarks, and that it's started when it isn't running yet, but the main point is that the bookmark server won't be a dpi plugin, or can't be because you can't use unix sockets as the current dpi system uses now (which is fine for a plugin system, but not when you want to connect to non-local pc's). Greetings, Indan