- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Dillo mailing list <dillo-dev@lists.auriga.wearlab.de>

by Jorge Arellano Cid

On Wed, Aug 10, 2005 at 08:10:23PM +0100, Jeremy Henty wrote: > > Jorge Arellano Cid wrote: > > > 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! > > Works great for me! (Linux 2.4.31-0 i586 unknown.) Good! Note: if you want to make it less verbose, just "#define DEBUG_LEVEL 8" in src/cookies.c. -- Cheers Jorge.-

Aug. 10, 2005

Dillo mailing list <dillo-dev@lists.auriga.wearlab.de>

by Jeremy Henty

Jorge Arellano Cid wrote: > 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! Works great for me! (Linux 2.4.31-0 i586 unknown.) Cheers, Jeremy

Aug. 10, 2005

exact meaning of "Handling of configuration data"

by Diego Sáenz

Hi, in the current plans page(http://www.dillo.org/Plans.html) there is a medium priority task named: - Handling of configuration data. By some comments in the list have some idea of the meaning of this, but what is exact meaning of "handling of configuration data"? Diego.

Aug. 9, 2005

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

by Jorgen Viksell

Hi, fre 2005-08-05 klockan 15:45 -0400 skrev Jorge Arellano Cid: > 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. I'll have a look at some options (including namazu mentioned by higuita). Browsed around some on the server and found that the list archives are located on it, so it should be quite easy... Will probably be done by wednesday! Cheers, Jörgen

Aug. 6, 2005

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