It looks like Alexander is correctly making it possible in GVFS to have a GInputStream, a GOutputStream and a GSeekable that has nothing to do with a GFile. It’s therefore possible that while it being a major API and ABI breakage, I will remove TnyStream from Tinymail’s API and adopt GVFS’s types for this in a second Tinymail version. I’m indeed already planning those API breakages ahead of time.
I’ll clarify why I think this is important.
In Tinymail a stream can have any source and any destination. For example a TCP stream that represents a connection with a IMAP server. A converting stream that gets as input the encoded MIME part of a message and outputs it decoded. A file stream that gets as input for example a decoded MIME part and as output a file.
Making any assumption about streams like that a stream always either originates from or results in a file, would make any of above situations impossible. The API for a ‘stream’ type therefore shouldn’t assume a lot of the rest of the virtual file system layer or assume the availability of for example a file descriptor (although I’m perfectly okay with ‘the VFS layer’ as location for a stream – API). In the end I hope to share that stream API with for example the implementers of future HTML render components. Then I can ‘stream’ the decoded MIME part to that HTML renderer. That the HTML renderer component will ask for ‘stream instances’ to the inline embedded images (in case the HTML E-mail has attached images being used in the document).
The thing is, that efficient mobile E-mail clients will not first download the entire E-mail to for example /tmp, in stead they will actually stream the MIME part on-demand straight from the IMAP server to a converting stream that decodes the MIME part and then stream that output straight to the HTML renderer. In the process it’s possible that I’ll put a ‘locally caching stream’ somewhere in between, yes.
This makes it possible to not cache attachments on a device with few disk resources, yet to do make them available when the user is online, yet to have it perfectly transparent IF caching attachments locally is to be done and IF it was done in the past. ‘Streaming’ doesn’t necessarily have anything to do with files, yet often does (like when caching certain streamable things, like files, locally).
I hope this is being kept in mind while designing GVFS, though it looks like the current API indeed allows this (so that’s excellent!). I’m definitely looking forward to having GVFS. It’s great to finally see Java and .NET’s streaming APIs being put in place. Very exciting to soon have this.