As part of my work on a Obs::Html module, I decided to test out very long playlists (in the order of 3000 tracks). As far as the CGI scripts were concerned, this didn't seem to be a problem, however it was taking mozilla (0.9.6) around 1000 secs (yes fifteen minutes) to render the resulting page.
Initially, I assumed a table with 3000 rows, was just too much for the lizard. However, I decided to run the output of playlist.pl through 'tidy' and then load as a static page. The result - 26 seconds. A 40 fold improvement. Anyway, it turns out that of all the thousands of errors that tidy reports, the problem that hits mozilla is that the form and the table on the page were not properly nested. i.e. we had <form><table></form></table> (also, the CGI script puts 3000 hidden fieldsjust before the </form> tag, which I don't think helps either). swapping the tags around to <form><table></table></form> Makes the problem go away. Unless anybody objects, I'll put a fix into CVS. On a related note.... the <meta http-equiv="Pragma" content="no-cache"> tag. That obs puts into each page, is going into the body of the document and not the head. AFAIK it won't work here. The manual for CGI says that most browsers don't cache CGI pages. However, we can get CGI to print the no-cache pragma as part of the real header by doing $o->cache(1); before we print the header. Also adding an expiry date can't help either. print $o->header(-expires=>'now'); Anyway, I assume that the meta tag was added to help out a particular browser? Any ideas of which? Would this more correct solution work? Rob -- ---------------------------------------------------- Remember: You are unique - just like everybody else. _______________________________________________ Obs-dev mailing list [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/obs-dev
