- Dillo-dev - lists.mailman3.com

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

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

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? Glyn

July 9, 2005

Re: [Dillo-dev]Meta-refresh warning

by Glyn Kennington

Glyn Kennington wrote: > I can write the necessary trivial patch to insert such a check if people > agree that it's The Right Thing, but I thought I'd better check that > I've interpreted the spec properly (and am reading the right bit of it) > before I do so. Well, as nobody's tried to put me right on this, here's some patches (taken against current CVS, and they can be applied to 0.8.5): First, the "safe" patch. This removes the reference to the spec's "explicit recommendation" if it's a simple refresh with no redirection. A warning is still generated. Second, the "controversial" patch ;-). This removes the warning altogether when the refresh doesn't involve redirection. Glyn

July 9, 2005

Re: [Dillo-dev]viewing non-web files

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 05 July 2005 19:55, Matthias Franz wrote: > On Tue, Jul 05, 2005 at 12:29:37PM +0200, Michael Kropfberger wrote: > > 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, > > which is problematic to some external programs > > If an external program needs a certain extension, it can set the > "nametemplate" field as defined in RFC 1524. Example: > > application/pdf; /usr/bin/xpdf '%s'; \ > test=test -n "$DISPLAY; nametemplate=%s.pdf THANKS for this hint!!! works great! > > 2) this creation of an extra copy temp file makes it unusable on > > handhelds, either memory- and performace-wise > > This might indeed be a problem. right now, I've written an ugly patch to directly override all dillo intelligence and pass a fixed extension (.mp4) to a video player... this is the only way to make it usable to play video off a SD-card... greets, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCy6hkw6IyDgGSsNIRAnfvAJ4gfeHNO96MVda6fh6+1Gp/NcPJwwCgi0YQ vTyPiSDH6J74EEJxMR/fmyA= =cgDY -----END PGP SIGNATURE-----

July 6, 2005

Re: [Dillo-dev]viewing non-web files

by Matthias Franz

On Tue, Jul 05, 2005 at 03:30:12AM +0200, Diego Sáenz wrote: > Why not to cordinate effors? What about a group to bring this feature to > "official" dillo? This is a good idea. I'm quite busy with my job, but I could contribute to such a project. As far as I know, Jorge would like to have an external viewer dpi in Dillo. Jorge: Correct me if this is wrong > That dpi must support mailcap already in the patch > It must use file if unknown the mime type, Currently the mime type is guessed in a_Misc_get_content_type_from_data (not part of the patch). I've added some more guesses in file.c. > but must use the mime type of the http headers if possible. done On Tue, Jul 05, 2005 at 12:29:37PM +0200, Michael Kropfberger wrote: > 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which > is problematic to some external programs If an external program needs a certain extension, it can set the "nametemplate" field as defined in RFC 1524. Example: application/pdf; /usr/bin/xpdf '%s'; \ test=test -n "$DISPLAY; nametemplate=%s.pdf The current patch implements this. > 2) this creation of an extra copy temp file makes it unusable on handhelds, > either memory- and performace-wise This might indeed be a problem. (Note: I'm away for the next couple of days.) All the best, -- Matthias Franz

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Diego Sáenz

1) use a tmp directory /tmp/dillo-zxqw34/file_with_original_name_and.ext 2) The temp file is not needed for local files(file://). About memory and performance: If the mime support is in dillo the size of the code is in memory all the time, substracting memory size to the program launched to view the file and other programs. If it is a filter DPI it only uses mem before launch the program. It can use exec to not use mem after launch the program or other ways. More about avoid temp files for local files Dillo send a dpi command to the DPI with a url of the file. For example: <dpi command='open_file?' url='protocol://path/file.ext' content-type='if dillo know it'> The DPI pass the /path/file.ext to program if the file is local or download it and pass the /tmp/dillo-zxqw34/file.ext file to the program. The mime DPI can, and surely need to, do protocol handling too. Diego Sáenz / Darkspirit El Tue, 5 Jul 2005 12:29:37 +0200 Michael Kropfberger <michael(a)kropfberger.com> escribio: ... > I'm also voting for having external mime support directly in dillo. > if there is a coordinated work is done, there is one prob with the avail > external patch: even when passed though the file.dpi (eg. file://myacro.pdf) > a new temp file is created and the external mime-viewer is called on this. > there are several problems: > 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which > is problematic to some external programs > 2) this creation of an extra copy temp file makes it unusable on handhelds, > either memory- and performace-wise > > > just my 2 cents, > > > Mike

July 5, 2005

Re: [Dillo-dev]viewing non-web files

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > That dpi must support mailcap because every linux distro and unix flavour > have it configured by default and some user too. It must use file if > unknown the mime type, but must use the mime type of the http headers if > possible. It needs to be configurable by the user, to display html pages to > ask the user if there are multiple acctions posible, available to call > other DPIs to manage some mime types, but all this can be add later when > basic funcionality is done. I'm also voting for having external mime support directly in dillo. if there is a coordinated work is done, there is one prob with the avail external patch: even when passed though the file.dpi (eg. file://myacro.pdf) a new temp file is created and the external mime-viewer is called on this. there are several problems: 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs 2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise just my 2 cents, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCymEUw6IyDgGSsNIRAr56AJ475U6rGOKGlxPrWaY5MhNm1EL9kwCeLrj7 iq1ZMcHP/feMV6ugh2kyrBM= =V1RP -----END PGP SIGNATURE-----

July 5, 2005