[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [eclipse-incubator-e4-dev]E4 towards generic connection management
- From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
- Date: Mon, 25 Aug 2008 12:26:44 +0200
- Delivered-to: firstname.lastname@example.org
- Thread-index: AckGaN/nCoDU+bQ1Rmy03DQZLckGzgAMFTUA
- Thread-topic: [eclipse-incubator-e4-dev]E4 towards generic connection management
The idea of making the Eclipse Workspace more flexible by
allowing arbitrary resources identified via URI has been
part of Eclipse since 3.2 through the Eclipse File System
While I really like that idea, my experience has shown,
though, that it is not sufficient to try and "remotify"
resources without the applications actually knowing
(just as Scott says). Even in the Platform itself, not all
components have migrated properly after 2 years ,
and due to the fact that the Workspace tries to perform
a deep global refresh, very bad Performance issues arise
when a user tries to link a slow remote file system into
his workspace .
There are architectural issues with the way the Workspace
currently works (and is expected to work by old-style
clients), which cannot be "remotified" properly .
So, I agree it makes sense to push down some network /
connection related concepts into the Platform and make
them First Class Citicens. But I doubt it's right doing
so on the IResource level. It's not only much work like
Jeff says, I think it's impossible getting it right when
trying to remain backward compatible.
I think that users do have an understanding of "local"
vs. "remote" things and what it means to "import" or
"synchronize", as well as be aware of issues like latency
or faulty connections. So, instead of trying to hide the
fact that things are remote, remote concepts need to be
made more explicit -- sometimes up to the Application level,
just as Scott says.
An idea like WebOS is great but it looks like that's exactly
what it does -- making every client of the OS aware of
network-related issues from the very start. We can't go
and plug this in under the existing Workspace.
 EFS Overview
 EFS migration guide
 Ant Editor doesn't work with remote files linked in through EFS
 Eclipse hangs when importing a project that contains a linked
resource for a large, slow, efs-ssh-shared file system
 ResourcesPlugin performs too many operations in its start() method
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member