> The HTTP filesystem may not know the file size until download is complete. > I think that the interface should change back to return a status, and > put the size into > a pointer if it can be done.
Sounds great to me. I had considered other ways of handling an unknown file size, but a pdf_status_t return value would do the job nicely. It seems like the change in return value to a pdf_size_t was based on an assumption that is no longer true: > Yes, definitely. Since pdf_fsys_file_get_size operates in a > pdf_fsys_file_t and not in a path we can expect that should not be no > error in the execution of the function. William Demchick On Tue, Nov 9, 2010 at 4:24 PM, Scott Fohey <sfo...@gmail.com> wrote: >> > > I would say to change the pdf_fsys_file_get size to >> > > >> > > pdf_size_t pdf_fsys_file_get_size (pdf_fsys_file_t file); >> > > >> > >> > Ok, should I change that? >> > >> > Please. >> > >> >> attached. I changed the disk implementation accordingly. >> >> Applied to the trunk. Many thanks. > > So, back in Aug of 2008 pdf_fsys_file_get_size was changed to return a > pdf_size_t. > > The HTTP filesystem may not know the file size until download is complete. > I think that the interface should change back to return a status, and > put the size into > a pointer if it can be done. > > Thoughts? > >
