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.-
Hi,
A simple flag, maybe in the DilloUrl or in the cache entry.
In the posted patch, I just added a reload_timeout in DilloUrl and a reload_timeout_tag in BrowserWindow. When viewing a DilloUrl with a non-zero DilloUrl::reload_timeout, BrowserWindow will start a single shot timer which tag is saved in BrowserWindow::reload_timeout_tag. This timer will trigger a reload (as if the user hit the reload button). The reload will restart the timer. If another DilloUrl is viewed, any pending timer is stopped (and the new DilloUrl is again tested for a non-zero DilloUrl::reload_timeout). I also added a_Url_set_reload() to set/unset that reload_timeout.
- 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
Internally, the command line options are translated to a linked list of commands, which are executed by the running instance, or sent to a running server. So I implemented both. The advantage of the "-c" option is that commands could support parameters as in: "open(URL newwindow reload=50)". It adds flexibility.
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!
I think it is easier to implement a remote command dpi than implementing a "reload dpi". The "reload" should only be one of the remote commands that a server must understand.
fprintf(reloads_dpi_socket, "push http://localhost/someurl visible\n");
may be all the client program needs to know.
Unfortunatly, fprintf does not work with Unix Domain Sockets but with pipes. Pipes have a limitation: if more than a client access to the pipe, the server could get mixed-up commands if the clients commands are larger than a system specific buffer size. For robustness, I will use UDS. If a client program wants to use dillo server capability, then we'd better provide a lib or a small C file.
Note that it may be good to integrate the remote control functionality into the same dpi (and maybe call it remote.dpi?).
Yes, I agree, the reload (and other functions) should be served by the remote control functionality. Whether it should be a plugin, I am not completly convinced, because it adds a little more complexity: At the current state of the dpid, we cannot run more than one dillo server (if we make exclusive use of the dpid framework). This is because for each service, there is only one socket. I think it is more flexible to have the possibility to have different dillo servers, each one with a distinct name provided by the user (or the application). For that, dpid should accept an additional parameter which is used to parametrize the socket name, e.g.: <dpi cmd="start_plugin" msg="dillo" param="cinepaint_help"> dpid will then look if a socket named: "/tmp/$USER-$RAND/dillo-server-$PARAM" ($PARAM being the value of the param tag) exist. If it does not exist, it would start the plugin with a special command line option: dillo -s $PARAM. This will require a way to tell the dpid how to call a parametrized plugin. Thus, relying on dpid to create the socket and run the server plugin would need some changes to dpid. An alternative solution, is to not rely on dpid but on dillo itself to start a server and to create the socket. The socket will be independent from the dpi_dir, and would be /tmp/dillo-$USER-$SERVERNAME. Subsequent communications could still use dpid's I/O functions.
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).
(if the application never starts a dillo instance, then there is no guarantee that there is a dpid running. Or you meant the API should take care of this, too?)
participants (2)
-
Jorge Arellano Cid -
Melvin Hadasht