[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: Tue, 01 Mar 2011 15:36:01 +0100

On 2011-03-01 at 10:29:56 [+0100], Clemens <clemens.zeidler@xxxxxxxxxxxxxx> 
> On Tue, 01 Mar 2011 04:26:55 +1300, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> >> 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.
> I though about file systems like google contacts or google picassa fs...
> I think all
> of theses fs needs some way to store cache files locally. Also you want to
> manipulate files in the fs. I could imagine that all this stuff looks the
> same for many usecases. Thus the lib should be for a fs module to make it
> easier to write a fs. Maybe hide the node stuff a bit...

OK, I see. One would probably approach this from the other direction and 
write a more or less generic file system with plug-ins for the various 

> > 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.
> Does it also handle the case when a app want to open an arbitrary file
> without knowing anything about "IMAP FS user@xxxxxxxx"?

Why would some app do that? At some point someone has to know what to mount 
where. If that is supposed to persistent it could be done via auto-mounting. 
Unfortunately, at least ATM, that wouldn't work particularly well with 

CU, Ingo

Other related posts: