views:

283

answers:

3

Hi, I need to write a text file viewer (not the directory tree, but the actual file contents) for use in a browser. It will be used to view large files. I want to give the user the ability to actually ummm, browse the file, ie prev page & next page buttons, while each page will show only a portion of the file.

Two question:

  • Is there anyway to pass the file descriptor through POST (or something) so that on each page I can keep reading from an already open file, and not starting all over again (again - huge files)
  • Is there a way to read the file backwards? Will be very useful for browsing back in a file.

Any other implementation ideas are very welcome. Thanks

+1  A: 

Cut your huge files into smaller files once, and then serve the small files to the user.

Zed
+2  A: 

Keeping the file open between requests is not a good idea - you don't have to "start all over again" - just maintain an offset and use fseek() to jump to that offset. That way, you can also implement the "backwards jumping".

Michael Borgwardt
Did just that. Work like a charm :D
MeLight
A: 

You should consider pagination. If you're concerned about the user being frustrated by needing to click "next" too often, you could make each chunk reasonably large (so a normal reader pages every 20min).

Another option is the Chunked-Endoding transfer type: Wikipedia Entry. This would allow your server to respond quickly and give the user something to read while it streams the rest of the file over the network (rather than the server needing to read in the file and send it all at once). This could dramatically improve the perceived performance compared to serving the files normally, but still consumes a lot of bandwidth for your server.

You might be able to simulate a large document with Javascript and AJAX, but only send pieces at a time for better performance.

Consider sending a few pages worth of your document and attaching listeners to the scroll event of your browser. Over time or as the user scrolls down you AJAX more chunks. This creates a few annoying UX edge cases, like:

  • Scroll bar indicates a much smaller document than there actually is
    • You might be able to avoid this by filling in the bottom of your document with many page breaks, but it'll be difficult to make the length perfect.
  • Scrolling past the point of currently-available content will show a blank page.
    • You could detect this using JavaScript and display a "loading" icon to let the user know what's going on.
  • Built-in "find" feature doesn't work
    • Hard to avoid this without the user downloading the entire document, but you could provide your own search feature for them to use instead (not as good but perhaps adequate).

Really though, you're probably best off with pagination with medium-sized pages. It's a very well understood design pattern that's a relatively easy (compared to other options at least) to implement and make fast.

Hope that helps!

etoleb
I actually went with the fseek() solution, was intuitive and pretty easy to implement. About the lots of paging problem - I've added a goto-line option so it's cool :) I probably got you confused, but I don't need this to keep the reader on my website - the reader doesn't want to be there in the first place lol. It's a simple way of showing some big text files we have here to other employees of our company abroad - so need nothing too fancy :)Thanks for the elaborative explanation though
MeLight