[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 15:16:59 +0200
Hi,
first of all, sorry for being under the impression that you disliked the
FS backend idea alltogether.
Am 30.03.2011 17:24, schrieb Adrien Destugues:
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 ...
...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.
>
Maybe I just fail to name this other metaphor properly, so I can't
register it as something that makes sense.
I'm thinking Tracker and Deskbar provide not only the access to files
and show which apps are running, they are the desktop and the main
interaction point with the system level features. I have no problem
extending the meaning of an icon in Tracker to represent an object of
information, independend of its storage location being local or remote.
I can even imagine icons to have more meanings. There are already icons
with more virtual, detached from the FS meaning, like the Trash icon or
the Disk icon. I can also imagine attached devices to be displayed as
icons on the desktop, like a scanner or a printer. IMHO an icon
certainly does not have to always represent a local file.
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.
>
I expect that from a network drive, because I mounted it. How would it
work to set up a people-folder from a mail account ? I guess this would
use some other UI, not right click>mount. So it may come unnoticed by
the user that these files are actually his remote contact list, not a
local copy, as people files currently are. This is actually a nice
feature, but only if we let the user know. How to do that ?
Well, I completely agree that the user needs to be aware that the
contents of the people FS are "virtual", mirrored and synchronized with
multiple address books at other places. Possibilities to get this awareness:
* In an empty People FS folder, display an icon "Configure contacts".
* In the E-Mail preflet, ask the user if he wants to import contacts
after configuring certain types of accounts. Explain what will happen,
how mirroring might work, etc.
* Explain it in the user guide
* Good error messages when trying to do impossible things in the FS
* ...
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.
>
I wonder what would be the expected result then ? Not allow the copy
because the source or the destination is unreachable ?
That is one certainly valid way of dealing with it. Another possibility
is to show the target as being unavailable in the first place.
> Again, this needs thinking.
Certainly. If I had to do the implementation, I'd think more about how
this could affect the overall design. Displaying and error or preventing
the operating is certainly not bad. In Thunderbird, I am allowed to
delete mails from an IMAP account while being offline. This gradually
improved in recent versions, I remember annoying error messages for each
deleted mail, I think meanwhile it will simply queue the request and do
it when the connection is available again. That could lead to the
situation you described, i.e. the copied contacts being stored in some
local command queue. With a warning displayed, you know what to expect
when looking at the target contact list from another computer before the
other one had a chance to carry out the operation.
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.
This time it's not about being simple, it's about the balance between
thinking and designing thing and actually writing code. As far as I
know, GSoC requires writing code explicitly, and a project like this
one, as challenging and interesting as it can be (as a student, I could
even want to do it), needs a long thinking time to get all the issues
solved, and I think that should be done before starting to write any
code. So maybe we can talk about it a bit more, and set up a more
complete proposal about it for GSoC 2012, or we can risk a student
spending a lot of think&design time and write little code, or write code
that we will drop later because it doesn't fit the needs.
Even in a single day of discussion, we can already think about many
relevant problems and possible solutions. Three month of fulltime work
is a lot of time. I am not a proponent of allowing only easy projects
where the student can get away with doing a lot less time than the
promised 30 to 40 hours a week.
Anyway, I think the argument of this being an R2 thing still stands.
Maybe we allow R2 things to be worked on as part of GSoC on purpose, I
don't remember what was the outcome on discussions about this...
It has happened in the past. Even when you worked on the Locale Kit, it
was not clear at all whether this might appear in R2 only.
Best regards,
-Stephan
Other related posts:
