[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: Anshul Singhle <xashck@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 15 Apr 2011 00:03:29 +0530
> But when an application posts a read request starting at a point
> in the file that isn't cached, the filesystem needs to go out and
> get the data to satisfy that request. That might be at position 0
> in the file, if I just do a "cat" on the file and the filesystem
> hasn't yet downloaded the full header.'
>
I don't really know how to implement this. Conceptually speaking, and
application can ask for a node and i can give it the contents of that node.
How will I know if the application is asking for data that is not stored in
a node. Can we have empty nodes? and can we know if an empty node is being
accessed?
> If it isn't feasible to support random access as described
> above, it still makes sense to support incremental download
> for sequential access. You don't need to download a part until
> I have asked to read it. If I read "off the end" of the cached
> data, but still inside the extent of the file as reported by
> RFC822.SIZE, then it's time to fetch more parts. I don't have
> to know the MIME structure of the file to do this, and of course
> I don't have to communicate it to the filesystem as such, I just
> ask for N bytes of data at file offset T.
>
> This seems doable.. How ever, if you can give me an example of some
existing implementation.. that would be great. One thing I'm not sure of is
whether you can set the size of a file. i.e. if you can tell the FS that
this file is x bits of data so allocate and index accordingly, even if in
reality i'm storing only y(<x) bits. I'm guessing this can be done using
blocks i.e you keep an empty block as a part of the node. So when you ask
for the contents of a node, it looks at all the blocks and gets an empty
block, so it calls a function which gathers from the context what data needs
to be fetched and accordingly fetches and stores that data.
> I think it will still be desirable to publish MIME structure,
> though, since applications need to know this, and I think you
> really have to support seek anyway, so maybe it boils down to
> the same implementation either way. If the difference is
> whether parts could be incrementally cached out of order, maybe
> that isn't such a good idea anyway, since the part boundaries
> won't line up with the block structure of the cache device.
> Just guessing on that.
>
I'm not sure there is a way to "get" the MIME structure without getting the
whole message. Will look for something.
Other related posts:
