[haiku-development] Re: Working on Caya and Mail app for GSoC
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 30 Mar 2011 13:01:04 +0200
Am 30.03.2011 15:36, schrieb Adrien Destugues:
* 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.
Note how you integrate rather different things, like dragging a text
selection and moving a file in Tracker, into the same metaphor (moving
something). I am not saying that is bad, I am just trying to make you
aware of it. Your comparison is completely arbitrary by picking a common
attribute, the mouse operation, to put two different things under the
same umbrella ...
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.
...At the same time, you do not want an integration of two (IMHO) much
less different things by another arbitrary common attribute, their
representation in Tracker. This is just refusing change for the sake of
keeping everything as it is.
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.
Nobody said anything about where the mount point should be. So why would
this be an argument against this backend?
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...
You've already said that and I've already admited that this backend has
issues of its own that need to be carefully addressed. You are not
claiming it's impossible to address the issues, so why would it be a
good argument against?
* 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.
Huh? Even the old BeOS could mount a network resource on the desktop. It
was totally clear to any user that the files appearing inside a folder
on the local desktop were actually remotely stored.
> 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.
You are stating the obvious. For various reasons, it is already clear
that making the data available while offline is desirable. Well, yes it
needs some smart and seamless implementation, what is your point? :-)
> 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...
You are completely making this up. The situation may be real, but the
result is completely in your mind. The implementation can be made to
anticipate it and handle it without bad effects to the user. The problem
actually exists for any other backend as well.
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.
Since when do GSoC projects have to be simple? There is a mentor and a
mentor pool for a reason.
Best regards,
-Stephan
Other related posts:
