- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Search feature for the mailing list

by higuita

On Fri, 5 Aug 2005 15:45:24 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Would you mind trying to find out a program that does this job > given the archives as input. i use namazu for local search and works well... isnt build for many users searchs at same time, but the mailing list is so small compared with all my files that shouldnt be a problem... it doesnt need any SQL database, so its light and easy to setup 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

Aug. 5, 2005

Re: [Dillo-dev] cookies dpi patch is on CVS now

by Diego Sáenz

El Fri, 5 Aug 2005 14:00:16 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi there, > > After a more in depth review, the patch for the cookies dpi was > uploaded to the CVS. It has some minor modifications and it's > ready for testing! > Then other thing to mark as in cvs in the current plans page. Thanks for the modifications, specially for MSG/_MSG and english corrections :P > Cookies now hare handled by a dpi (dillo plugin), so there's no > more restriction of only one instance of Dillo having cookies > enabled. Every single dillo sees cookies.dpi as the "cookies > server" so there's no problem, and dillo's core gets smaller. > > After 'make", remember to "dpidc stop" and to 'make install' to > get the cookies dpi installed. > > If you find some bugs, please report back here to Diego or me. > > Diego: I'll try to catch up with the thread about the MIME dpi. > As Matthias Franz pointed out, I'm interested on it. The main > point is to make it use the dpi/dpip framework instead of a > custom approach. --More on this soon. I think that the way to register dpis and the mime that each dpi understand is needed before that. If dillo use mailcap then it will have a lot of configuration done, but dillo need to support dpis for mime too so they work with dillo better. I am open to change mi opinion with a better solution, of course. > > I'm also working on a new dpip library, so it may be merged in > the future (don't worry, that's my work and it makes things > easier, not harder). Porting the cookies dpi to it should be no > more than one day, and I have already every other dpi working on > it on a custom tree... I await it. > > > -- > Cheers > Jorge.- > Diego Sáenz / Darkspirit

Aug. 5, 2005

Search feature for the mailing list

by Jorge Arellano Cid

Hi Jörgen, The mailing list "search" page is consistently working bad. Would you mind trying to find out a program that does this job given the archives as input. (the archives are available from: http://lists.auriga.wearlab.de/pipermail/dillo-dev/) I'd like to haveit running on site, otherwise it gets very hard for non-subscribed people to search the mailing list for some information. TIA. -- Cheers Jorge.-

Aug. 5, 2005

cookies dpi patch is on CVS now

by Jorge Arellano Cid

Hi there, After a more in depth review, the patch for the cookies dpi was uploaded to the CVS. It has some minor modifications and it's ready for testing! Cookies now hare handled by a dpi (dillo plugin), so there's no more restriction of only one instance of Dillo having cookies enabled. Every single dillo sees cookies.dpi as the "cookies server" so there's no problem, and dillo's core gets smaller. After 'make", remember to "dpidc stop" and to 'make install' to get the cookies dpi installed. If you find some bugs, please report back here to Diego or me. Diego: I'll try to catch up with the thread about the MIME dpi. As Matthias Franz pointed out, I'm interested on it. The main point is to make it use the dpi/dpip framework instead of a custom approach. --More on this soon. I'm also working on a new dpip library, so it may be merged in the future (don't worry, that's my work and it makes things easier, not harder). Porting the cookies dpi to it should be no more than one day, and I have already every other dpi working on it on a custom tree... -- Cheers Jorge.-

Aug. 5, 2005

News after LSM 2005

by Jorge Arellano Cid

Hi there! It's being some time since coming back from France, but I'm catching up. There's a new link for "LSM 2005", and there's a video URL for those interested. Ah, Philippe De Swert, made a Debian package for x86 with dillo-0.8.5. It is available from the downloads page. Please let the Debian guys know so they can get it, and try it, tell them to report back here in case the package needs some polishing. It's being a lot of work with these conferences. I'll report here more news when we sort out what to do in the near future. The FLTK2-based prototype is not ready yet for CVS and this is one of the things we're deciding on with Sebastian. Diego: please check and send me the cookies patch to upload it to the CVS (and to merge with the prototype). The server was down several days because it was hacked. Now it's working normally again, reinstalled on another machine. This probably explains why it was so hard to get in touch with it. :-) -- Cheers Jorge.-

Aug. 2, 2005

Re: [Dillo-dev]Meta-refresh warning

by Alexander Becher

Glyn Kennington schrieb: >> -r only refresh >> -rr redirect too > >I'll get to work on that. I'm not sure if "-rr" breaks certain coding >standards, it being neither a "short" (only one character) nor "long" >(starting with two dashes) option, but that's not especially important >(to me) right now. How about "-R" for "redirect too"? Also, dillo's error message when parsing the command line is not very helpful: |$ dillo -help |Error in command line options. Maybe at some time I'll look into making this more specific. >> but I think that dillo could not complain about refresh because they >> are HTML-standard compliant and it is the reason because meta-refresh >> was been invented. So if we would stay on the standards we have to >> accept it even if we don't like it. > >It's dubious whether it's standard HTML, actually. The spec says that >the "http-equiv" must be valid HTTP, effectively passing the buck to the >HTTP spec. And as the HTTP spec is in a fairly unreadable RFC format, >I'm still uncertain about all this... Actually, as I read it, the META-refresh is not an HTTP header at all. At least it does not occur anywhere in the HTTP spec. The HTML 4.0 spec says: Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. <META http-equiv="refresh" content="3,http://www.acme.com/intro.html"> The content is a number specifying the delay in seconds, followed by the URI to load when the time is up. [...] However, since some user agents do not support this mechanism, [...] Regards Alexander -- PGP key available Port Payé / Entgelt bezahlt / Postage Paid: http://www.hashcash.org/

July 13, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Glyn Kennington wrote: > Roberto A. Foglietta wrote: > > -r only refresh > > -rr redirect too > > I'll get to work on that. OK, here's one very poorly tested diff. Apply it after applying the main "refresh" patch. It should work against current CVS, nothing else tried. It's a bit of a hack, but no more so than your own patch ;-) I'll leave the timelimit part until I've thought about it a bit more. Glyn

July 12, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Roberto A. Foglietta wrote: > Glyn Kennington ha scritto: > >Rather than changing the first to be "refresh only, no redirect", could > >I suggest some kind of choice between the following three? > > > >1: no refresh > >2: refreshes allowed, redirects not > >3: refreshes + redirects permitted > > > >[...] > > that sounds good: > > -r only refresh > -rr redirect too I'll get to work on that. I'm not sure if "-rr" breaks certain coding standards, it being neither a "short" (only one character) nor "long" (starting with two dashes) option, but that's not especially important (to me) right now. > but I think that dillo could not complain about refresh because they > are HTML-standard compliant and it is the reason because meta-refresh > was been invented. So if we would stay on the standards we have to > accept it even if we don't like it. It's dubious whether it's standard HTML, actually. The spec says that the "http-equiv" must be valid HTTP, effectively passing the buck to the HTTP spec. And as the HTTP spec is in a fairly unreadable RFC format, I'm still uncertain about all this... Glyn

July 12, 2005

Re: [Dillo-dev]Meta-refresh warning

by Roberto A. Foglietta

Glyn Kennington ha scritto: > Roberto A. Foglietta wrote: > >> http://www.roberto.foglietta.name/pub/dillo/ >> >> It able to refresh AND redirect, but only if -r option is specified in >>command line. May be you can modify it to refresh ALWAYS and use -r >>option ONLY for redirect when time is more than the specified offset >> >> -r <seconds> > > > The more I think about how I'd go about hacking this functionality in, > the more questions it brings up... > > As well as a time boundary, I think it would probably be best to include > another option to specify which refreshes to honour. At the moment it's > a simple choice between > > 1 (default): no refresh > 2 (with -r): all refreshes permitted > > Rather than changing the first to be "refresh only, no redirect", could > I suggest some kind of choice between the following three? > > 1: no refresh > 2: refreshes allowed, redirects not > 3: refreshes + redirects permitted > > And then we get into the murky area of limiting the times for these. > Could/should it be a different value for refreshes and for redirects? > What to do if the page requests a shorter timeout than allowed: ignore > it altogether, or handle after the minimum timeout has elapsed? > > Is that too many command-line options? Would an entry (or several) in > dillorc be more suitable? > that sounds good: -r only refresh -rr redirect too but I think that dillo could not complain about refresh because they are HTML-standard compliant and it is the reason because meta-refresh was been invented. So if we would stay on the standards we have to accept it even if we don't like it. The reason because I decided not to include the option in dillorc is beacuse -r -rr could be an alias which the user could setup in his/her shellrc while dillorc could be modified acrivating the option by distribution without knowledge of end-users. In this last case safe behaviure of dillo would be overloaded out of our/end-user control. Warning on refresh are very boring and fails completely in automated systems like embedded while warning on redirect could be much more acceptable for end users. So I think my patch was not so much usefull if dillo was HTML-stadard compliant but because my refresh needs we could discover (and sombody else) fix a very evil memory leak bug in pthread library. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

July 11, 2005

[Dillo-dev][PATCH] use an alternative rcfile from command line

by Tito

Hi to all, this little patch adds a command line option ( -R --rcfile) to specify an alternative rcfile from the command line. This is useful if you are calling dillo from scripts or other applications and you need to enable/disable some options for a particular task. The patch is against dillo 8.5. Please apply if you think it is ok to do so and the patch fits in the dillo philisophy. Ciao, Tito

July 10, 2005