You just seem reluctant to the idea for no good reasons (IMHO). That
you can't see the files when you are offline is not a fact, but
completely in your mind, it can be solved simply with local caching.
It's an implementation detail and any network file system needs to
deal with being offline anyway (queue local changes, synchronize).
That's the whole point of putting the functionality into the FS -
making this transparent to applications.
As for moving other types of files into the people folder - why can't
the FS reject that and return a meaningful error? Now, whether or not
you consider it a serious drawback is a question. I think nothing
prevents you from not using the feature, simply store real Person
files elsewhere, along with any other type of file you wish. The
People file system is still a neat idea, since it solves a serious
problem. One that is way more annoying and confusing than not being
able to store any type of file in the people folder.
Lack of transparency on how things work would be the main argument. The
people folder was there for a long time as an usual folder, and suddenly
with this it becomes something stored on the internet, somewhere. It can
still be accessible with local caching, so the fact that it's an
internet folder is hidden.
I see different problems :
* This file system is not able to store actual files, so to me it sounds
like an abuse of an existing API. It solves the problem, yes, but it's a
hack, not a clean and beautiful solution. Maybe it's just a matter of
renaming "file system" :)
* The impossibility to store regular files in this folder can be solved
with a meaningful error message. But what about moving person file from
this FS to outside of it ? users may find their jabber contact list
emptied by just trying to clean up their home directory. (and same for
emails, moving them out of the IMAP-FS has the unwanted side effect of
deleting them from the server)
* The reverse way, some sensitive info may end up exposed to everyone on
the internet by not knowing that this folder is actually not local to
the computer. This is a security concern.
I don't say it's completely a bad idea, all of this can likely be solved
in some way or another, but it needs careful thinking. All of this
alsosounds like a move to cloud computing, which I don't think I like
much. The local computer becomes, as you say, a cache for remote data. I
want my computer to be the primary storage, and the remote server to be
a mean of sharing the data to other computers. On the technical side
this may end up being the same, but it's conceptually very different.
Also, does it make sense from a programmer point of view ? A dedicated
People API would allow apps to easily query for person on various
attributes. I don't think it makes sense to use the file API for this,
even if it features the right functions.
So, on the technical side I agree it's fine, but I think t's confusing
for the end user, and that will create problems because users will do
wrong things. The UI may be special-cased around it with error/warning
messages, special icons, and all, but then, what's the point of using
Tracker if it works all different in the end ?
