[haiku-development] Re: GSOC: IMAP as a Local File System
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 03 Apr 2012 11:40:44 +0200
anil kag wrote:
> On Mon, Apr 2, 2012 at 11:05 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > Ingo Weinhold wrote:
> > > Ingo Weinhold wrote:
> > > > As you can see, the parse_parameters() function expects the parameters
> > to consist of the client FS name separated by whitespace from the following
> > (optional) client FS parameters. This is not driver settings format [1]
> > (note: Haiku extends the original format). That the driver settings format
> > is used for mount parameters is merely a convention we introduced. BeOS
> > didn't and ATM Haiku doesn't care: the string supplied to the mount command
> > is just passed through to the FS module. Eventually we might change that
> > e.g. to allow passing parameters that the VFS interprets (currently there's
> > only a flags array that can be used for that purpose in a limited way).
> > That, however, requires all file systems to respect the format.
> > > >
> > > > ATM solving that TODO in the userlandfs kernel module would add a bit
> > of inconvenience, though. Since you'd have to mount via something like:
> > > >
> > > > mount -t userlandfs -p "userlandfsClient=<clientFS> ..." ...
> > > >
> > > > instead of just
> >
> > mount -t userlandfs -p "<clientFS> ..." ...
> >
> > Ideally the TODO should be solved after integrating userlandfs better with
> > the system, so that userland client FSs are considered automatically when
> > mounting or/and there's an extra switch to force them. Like:
> >
> > mount -u <clientFS> -p ... ...
There's actually a "-t" missing. The "-u" was intended to force checking only
userland FSs. Without it the kernel would first look for a kernel FS, then for
a userland one.
> > Sir, that means i need to first integrate the userlandfs such that the
> client FSs are considered automatically... For this, where should i make
> changes(is it a configuration setting?? ) ??
No, this is not just a configuration setting. Full integration means that
userland FSs would be used more or less transparently like kernel FSs. That
would require changes in the kernel code that manages the FSs, in the code that
mounts them, as well as in the disk device manager which is responsible for
identifying FSs on partitions using the FS modules.
> > [...]
> > > > > --> things which are in my mind currently but i'm not upto the mark
> > to give
> > > > > a solution
> > > > > a) about the local caching in order to increase the performance....
> > > > > b) as i need to access an IMAP account i was thinking of using the
> > haiku's
> > > > > home grown code for working with IMAP, and as pointed by someone on
> > IRC..
> > > > > that it has some problems (some mails are lost while fetching..)
> > ---> can i
> > > > > use it or use something else(any other library for IMAP access). I
> > can look
> > > > > into fixing haiku's code for IMAP access.
> >
> > Both options are acceptable in principle.
> >
> > for a)--> Does the implementations given for the cache related hooks in
> fs_modules.h corresponds to this cache option???
The caching interfaces the kernel provides are all used to cache recently used
data in memory. That is unrelated to the local caching mentioned in the project
idea, which is supposed to do long term caching on disk.
> for b)--> Should i go for changes in the haiku's native code for IMAP
> access??
As I wrote, both options are acceptable in principle. I'm unfamiliar with the
IMAP code, so I don't have an opinion on whether any option is preferrable. You
could look at the code and form an opinion for yourself.
CU, Ingo
Other related posts:
