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