[Dillo-dev]meta refresh patch for 0.8.2
Hi to all, actually I'm working for a local public transport company in which I have to develop a new way to display time table and information to people. Using Dillo into embedded linux system allow my collegues to change graphical display just editing php code in the server BUT this kind of information have to stay up-to-date. Commit a refresh from server is, in this case, the best solution I can immagine. So supporting meta refresh tag makes Dillo good for embedded client systems. This is the main reason because I developed this web-deprecated but very-useful-in-embedded function. In addition to this pratical consideration I think people use free software to be free, so it makes sense give them the freedoom to choose also deprecated functions. Obviously to respect Dillo's team decision to do not allow refresh as default policy I make it optional by setting a flag from command line The patch is plenty of /* RAF, 2004-10-XX: bla bla */ comments because they are usefull for others developers inside my company when they will patch an original version of Dillo and found quickly what I have changed in. If you agree to apply this patch to future stable branches this kind of comments are not any more usefull. If you will include my patch, in agreement with gpl, please inserit somewhere a noticed of code-contribution refering me and the company which is employing me actually. Patch doens't add the memory leak bug which I submit, simply it was the way I discovered that bug. 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
On Thu, Oct 28, 2004 at 11:02:17AM +0200, Roberto A. Foglietta wrote:
Obviously to respect Dillo's team decision to do not allow refresh as default policy I make it optional by setting a flag from command line
speaking of patches, i have finished the caching work yesterday, and need some people to look at it and test it. it uses .dillo/cacherc to control which sites are allowed to set the browser to not cache the pages there, and also, it only currently honors Pragma no-cache. i want to modify the control functions to live in a public place and be generic enough that they can be used for anything, since all i did was copy them out of cookies.c and changed all occurances of Cookie or Cookies to Cache so the functions themselves don't change. once done, this could very easily be applied to the refresh tag to control that, and in fact, could be applied to any tag whatsoever at that point. here is the patch, let me know what you think, it patches against: /cache.c/1.74/Mon Oct 25 22:49:26 2004// /cache.h/1.18/Thu Oct 21 14:45:51 2004// /html.c/1.219/Thu Oct 21 22:48:54 2004// -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.
What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? DarkSpirit. El Thu, 28 Oct 2004 08:05:20 -0400 Brian Hechinger <wonko@4amlunch.net> escribio:
On Thu, Oct 28, 2004 at 11:02:17AM +0200, Roberto A. Foglietta wrote:
Obviously to respect Dillo's team decision to do not allow refresh as default policy I make it optional by setting a flag from command line
speaking of patches, i have finished the caching work yesterday, and need some people to look at it and test it.
it uses .dillo/cacherc to control which sites are allowed to set the browser to not cache the pages there, and also, it only currently honors Pragma no-cache.
i want to modify the control functions to live in a public place and be generic enough that they can be used for anything, since all i did was copy them out of cookies.c and changed all occurances of Cookie or Cookies to Cache so the functions themselves don't change.
once done, this could very easily be applied to the refresh tag to control that, and in fact, could be applied to any tag whatsoever at that point.
here is the patch, let me know what you think, it patches against:
/cache.c/1.74/Mon Oct 25 22:49:26 2004// /cache.h/1.18/Thu Oct 21 14:45:51 2004// /html.c/1.219/Thu Oct 21 22:48:54 2004//
-brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.
On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote:
What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION?
nothing, i just wanted to keep the code as identical to the original cookie version for now until it is decided what is going to be done with that hunk of code. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.
Hi Brian, Sorry for the delayed answer, I had a lot of work with the release and now I'm trying to catch up. On Thu, Oct 28, 2004 at 12:17:29PM -0400, Brian Hechinger wrote:
On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote:
What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION?
nothing, i just wanted to keep the code as identical to the original cookie version for now until it is decided what is going to be done with that hunk of code.
Cookies will most probably end being a dpi server (to solve the problem of enabling cookies in multiple Dillo instances). This was planned long ago and hasn't been realized because of lack of manpower (aka priorities :-). The configuration data problem (cacherc, cookiesrc, dillorc, <dpi-name>rc) is also a general issue that we're considering with Sebastian. Maybe it will all end in a generic preferences dpi; this needs some further thought. Soon a prioritized task list will be available in dillo-dev (I just sent back a good draft to Seb.). This account for what we, the core developers, will be doing the next months. The good news is that tasks that get lower priorities can be advanced by the interested volunteers. Please stay tuned, we're trying to cope with all the work we have, by organizing the work. The cache issues intersect with SSL (needs cache control), preferences handling, cookies dpi server, and the universal CCC branch idea). When the commented task list is posted, you'll get the idea. -- Cheers Jorge.-
On Fri, Oct 29, 2004 at 02:58:20PM -0300, Jorge Arellano Cid wrote:
Hi Brian,
Sorry for the delayed answer, I had a lot of work with the release and now I'm trying to catch up.
not a problem.
Cookies will most probably end being a dpi server (to solve the problem of enabling cookies in multiple Dillo instances). This was planned long ago and hasn't been realized because of lack of manpower (aka priorities :-).
ok.
The configuration data problem (cacherc, cookiesrc, dillorc, <dpi-name>rc) is also a general issue that we're considering with Sebastian. Maybe it will all end in a generic preferences dpi; this needs some further thought.
ok, in that case, i'm going to leave things as they are the way i did them for now, when it is decided how configuration will be handled, i'd be more than happy to work on that to get it done.
Soon a prioritized task list will be available in dillo-dev (I just sent back a good draft to Seb.). This account for what we, the core developers, will be doing the next months.
ok, i can't wait!!
The good news is that tasks that get lower priorities can be advanced by the interested volunteers.
you can count me in on this as well.
Please stay tuned, we're trying to cope with all the work we have, by organizing the work. The cache issues intersect with SSL (needs cache control), preferences handling, cookies dpi server, and the universal CCC branch idea). When the commented task list is posted, you'll get the idea.
ok, at that point we can start discussing how things will be done as relates to what i've been working on. i'll wait till then! -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.
participants (4)
-
Brian Hechinger -
Diego Sáenz -
Jorge Arellano Cid -
Roberto A. Foglietta