Comment 11 for bug 1659027

Yes we will have to carefully consider any stream, but stream
availability and I/O failures would be handled by the object derived
from the base stream object. Even file streams can have issues since
the file could just as easily be on a remote drive that is no longer
available or fails during the file read. Initially file and string
streams are adequate for what we are currently doing but using streams
or a stream type I/O prevent us from having to completely rewrite the
plugin I/O code when we want to add features like socket or archive
streams or some stream we haven't even dreamed up yet.

On 2/1/2017 4:12 PM, Cirilo Bernardo wrote:
> I think we need a clear idea of how to work with streams and how
> different stream data might be handled. In the past, networked virtual
> directories were popular for local nets but of course the data rates can
> be very high. If we plan to pull things off the internet I think we need
> to think about how to manage data usage; what to transfer and when, and
> how to handle situations where the remote data is no longer there. For
> many programs, streams must also be seekable. We can break so many
> things in a very bad way and I'm not currently convinced that the github
> retrieval of footprints works in a reasonable way. Features are nice,
> but if they introduce too many additional failure mechanisms we've got
> to put more thought into things.
>