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 ...Maybe I just fail to name this other metaphor properly, so I can't register it as something that makes sense....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.
It is not, I'm not blocking anything, the backend may be fine, I'm just trying to think about the possible problems and solutions.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?
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?
It's not.
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 ?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 wonder what would be the expected result then ? Not allow the copy because the source or the destination is unreachable ? Again, this needs thinking.> I can't imagine how messy it can get if youstart to movethings 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.
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.
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...
-- Adrien.
