[haiku-development] Re: Working on Caya and Mail app for GSoC
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 31 Mar 2011 14:35:54 +0200
On 2011-03-30 at 22:24:06 [+0200], Stephan Aßmus <superstippi@xxxxxx> wrote:
> Am 30.03.2011 19:01, schrieb Ingo Weinhold:
> > IMAP is an obvious candidate for a FS, as the service is pretty close to a
> > network FS already. (I'm no longer sure whether implementing caching and
> > an
> > offline mode in the FS itself is that good idea, though.) Contact
> > management
> > seems a lot less obvious IMO, since it's not strictly client-server,
> > unless
> > you really store all contacts on a single server and sync all your devices
> > directly against it.
>
> IMAP works fairly well in Thunderbird and other mail clients without
> being implemented as an FS.
Which is neither a pro nor a con for us implementing it as a FS or not.
> The reason why it would be good as an FS in
> Haiku is because you want to manage the mails via Tracker, Mail and
> possibly other mail clients.
IMO, more importantly, because mails are actually text files.
> The same reasoning applies to contacts as
> Person files, IMHO.
Mail files contain the main information in their file data. Mail readers
support the content format directly. The attributes just mirror some of the
content, and there are a few more attributes for adminstrative purposes,
improving management in Tracker, and allowing for queries.
Person files are completely artificial. I manage them in Tracker only because
there is no alternative and I have never had the need to query for them.
Application developers would be far happier with a dedicated API for
accessing and managing contacts than with using the file system API for that.
> The point isn't whether the service is similar to an
> FS, but whether or not you want multiple access points to the data, like
> Tracker and various other applications, to work in a robust way.
The file system provides persistence for generic data. Attributes only add a
mild degree of structure. No, the interface is anything but robust. I can
misspell attribute names or write random content into any attribute. Should
we ever make the Person file content vCard format, every application changing
contacts would also have to support vCard format directly. A dedicated API is
more than desirable. Which in turn makes the data storage backend of no
relevance and would also allow to hide the nasty details of synchronization.
Anyway, not having a contact management application (but instead a contact
management preflet for configuring servers *ugh*) we have to provide
management functionality via Tracker. Which means ATM we have to stick with
files. However, it does not mean a file system is necessary or even a good
choice. A daemon could provide the synchronization functionality just as
well. With the advantage that it could be implemented fully in userland (with
add-ons for the various services).
CU, Ingo
Other related posts:
