[haiku-commits] Re: r40736 - in haiku/trunk/src/add-ons/mail_daemon/inbound_protocols/imap: . imap_lib
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 28 Feb 2011 16:26:55 +0100
On 2011-02-28 at 11:43:53 [+0100], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> By the way what's about query support? Is there anything planned /
> implemented for package fs?
There's nothing implemented yet. Adding it shouldn't be all that
complicated. I suppose most of the code can even be borrowed from my RAM FS.
> How to integrate it into the tracker find
> window? I mean the current mounted volume approach would be not very
> handy.
Good point. I guess automatically adding all packagefs volumes mounted
somewhere under the selected volume(s) to the query would do the trick.
Maybe a volume flag indicating whether that should be the default behavior
for the volume could be introduced.
> Is there any lib for this planned? Since I can think of many of
> these fs's it would be nice to have some support libs.
>
> stuff for a fs support lib:
> - store files in a flat file (think could be taken from package fs)
> - query/indexing stuff
> - api to add, remove, rename... files inclusive hook functions
I'm not entirely sure I see where such a library would be used (by the FS
module?) and what you mean by the listed items.
Regarding query support, IMO that should be moved out of the file systems
into a dedicated service (post R1).
> - startup time, on boot the mounting of all these fs would take some time.
> Some apps may rely on files from these fs so you have to wait till all fs
> are mounted and afterwards continue with the boot script. My idea would be
> to mount the fs immediately into a blocking mode and load the files
> structure of the fs in the background. In this way you don't have to wait
> till the fs is mounted. If an app tries to access a file in the fs tree,
> the fs call simply blocks till the mount is complete. All independent apps
> could start working immediately.
Eventually something we need anyway is some kind of services/event daemon
which can start services, serializing dependencies as needed. It would be
straight forward to provide a simple API that allows to request services
(e.g. "IMAP FS user@xxxxxxxx") and wait for their availability. That's far
simpler than hacking lazy mounting support into a file system.
> We should think about something like this
> for package fs.
IIRC Oliver already mentioned in his blog that some kind of caching to
speed up mounting should be implemented eventually. The simplest solution
would be to write the in-memory structure to some cache file and when
mounting and the packages have not changed, just read it in again. I guess
that alone should decrease the mount times to harmless values. As a further
optimization the cache file could be structured in such a way that only the
actually requested data could be read on demand. That would also minimize
the memory footprint.
CU, Ingo
Other related posts:
