On Wed, 20 Aug 2003, Melvin Hadasht wrote:
Hi Jorge & Melvin,
Hi Henning & Jorge,
(Is there a reason why this is not on the ML?)
The only reason is that I pressed "reply" on a mail sent to my personal address. :-)
there's one bit missing. there is NO concept at all about time-based reloads. the meta refresh header would be reasonably close, but even better would be something like
dillo -reload-every 60 http://blah/cgi-bin/blubb.cgi
it should reload that URL every 60 seconds in that case no matter what.
I think reloading it if upon display is also a good choice. I mean, let the user browse other pages without reloading the special URL, and reload it when it's back on display and the timeout has been reached.
I don't see why a browser should reload an URL if it is not currently viewed, but I'm not a web expert.
I looked into adding a sigalrm handler an solving it this way, but then it turned out that is more complicated
We can use the glib timeout functions for that.
Yes, timeouts are simpler.
Here is how I would implement the feature:
- an internal Dillo function to mark/unmark a URL with "reload periodically when viewed",
A simple flag, maybe in the DilloUrl or in the cache entry.
it will also create a timeout callback that will reload the URL if it is currently viewed. A periodiciy of 0 will stop reloading. For that, I need to take a look on the browser history/cache, too.
Don't worry, I can do that easily (I know pretty well the cache). I'd prefer you to focus on the dpi part. I mean, this dpi will end asking dillo to do the job. For instance: <dpi cmd='set_reload_URL' url='...' always='true'>
- add a "-r, --reload-every" command line option that calls that function. In fact, when I finish implementing the "(remote-)command" option, it would be something like: "-c open(URL, refresh=60)" (that is if I finally decide that supporting commands with more than one argument is worth the work).
Hmmm, I think a simple cli switch to tell dillo to listen to the reloads.dpi is enough: dillo -reloads (or something like it) Then, the client communicates with the dpi socket. All this API is what needs to be designed. I'd appreciate you to work on this part.
The first duty is to define what is required for a good, general purpose, kind of reloading dpi. The next one is to reduce the features to a minimum working set, then implement!
parameters: URL, periodicity (seconds), when (visible|always).
This is a good start! For instance: fprintf(reloads_dpi_socket, "push http://localhost/someurl visible\n"); may be all the client program needs to know. Of course it could also be something like: fprintf(reloads_dpi_socket, "<dpi cmd='reloads' url='http://localhost/someurl' visible>" * The first example makes more clear that it goes trough reloads.dpi who parses it and then sends a dpip tag to dillo to request the job done. This may also be handy: "<dpi cmd='reloads' url='http://localhost/someurl' stop>" Note that it may be good to integrate the remote control functionality into the same dpi (and maybe call it remote.dpi?). This means adding a simple and useful API for help programs to use. For instance to let them push new URLs into the same instance of dillo (and not having to start a new dillo per requested page). Ex: The client app. asks the remote control dpi whether there's a running instance of dillo. YES -> send new to-be-pushed URL NO -> start "dillo -rc" (remote control) send new to-be-pushed URL Please polish along these lines. Cheers Jorge.-