[haiku-development] Re: Working on Caya and Mail app for GSoC
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 30 Mar 2011 14:36:59 +0100
* IMHO the simplicity and transparency of BeOS/Haiku has been misused
too often recently to try and stop certain new features from being
implemented certain ways or being implemented at all. It's an argument
that I look at very carefully before accepting it applies in a given
situation. After all, each of us knows awfully little about how
computers work at various levels. That's perfectly ok, don't get me
wrong. When we *perceive* we know how one thing works, we can't always
argue it becomes more difficult or is not simple anymore when a new
concept is embraced in that thing.
I don't think simplicity is about removing feature ; more about the same
representation (an icon in tracker) meaning the same thing (a file on a
disk), and the same thing always being represented by the same visual.
we have the same problem with localization : file name and application
name are no more the same. Here, icons may be local files or remote
data. It's also about things working the same way : by dragging things
around I expect them to be copied or moved, and this works everywhere :
from StyledEdit selection to a text file in tracker, from a tracker
window to another or to terminal, and so on.
I see this jabber-FS as a break in this, it creates files where I can
store no data, and moving them around actully delete them from a server
somewhere else. Because they look like files, I don't think that this is
the expected behaviour. This is where simplicity gets lost : not because
it is different than what was before, but because now it is not uniform.
The same problem can happen if this FS is mounted in a folder inside the
home directory (replacing the existing "people" folder). While this is
allowed in Haiku, it's more expected that different volumes are shown as
such on the desktop, and not mounted in strange places like this.
Again, there is likely a solution to this, maybe it is possible to add
some visual hint at this folder being special, giving it a different
icon or color. But I think this would be a workaround : we are trying to
get things integrated in Tracker, and we would end up marking them as
different, that means the integration has failed. I'm afraid I have no
good solution to that, however...
* The whole cloud thing wouldn't be an issue if people were not
facing the fact that they need to keep data synchronized transparently
over several of their own devices, or that some data is stored
completely elsewhere entirely. Trying to provide a solution for these
challenges is not a bad thing. It should not be shut out because it
makes a computer less transparent. The FS idea is a solution which
enforces consistency and avoids several points of failure that other
solutions may have. Thus it has the potential of making the live of
users easier. You are correct that it creates some issues of its own
that need careful solutions.
Cloud computing by itself may not be a bad thing, but I believe it's not
going to mix with the traditional filesystem this way. I think the best
we can get is look like a failed attempt at doing it too early. Some
icons will be local files, some will be remote data, moving things
around them creates possibly unwanted network traffic. Also, the fact
that it needs a cache for offline availability means while there is no
internet access, it's possible to do anything with the file, and we'll
need to keep track of it to sync back on the next connection to
internet. I can't imagine how messy it can get if youstart to move
things around from one online server to another one wich is unreachable.
Your data is removed from the first server, and while you expect it to
be stored on the other one, it's actually locked in a cache on your
computer...
So, a filesystem may be the answer on a technical side, but it needs a
lot of thinking and design, if we want to keep things uniform, and it's
an important choice. Much more than "let's just code it and see how it
works". Should we start it before R1 is released ? And as a GSoC
project, which will be handled by someone external to the core
developper team ? Knowing that GSoC is meant to be about code, I think
this needs a bit too much thinking and design for it. That doesn't mean
we should drop it altogether, but think about it for some time and go
for it later, maybe.
Best regards,
-Stephan
Other related posts:
