[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] E4 towards generic connection management (was: e4 beyond the ongoing UI conversations...)
|
Thanks John for the excellent background.
One thought I had that was sparked by your posting is that it might be
appropriate to build in support for remoting and caching for multiple
layers, so that applications could use the appropriate mechanisms given
their requirements. So remoting and caching could be at
application (UI model) -> remote services, explicit (i.e. user driven)
synchronization (e.g. CVS) or auto sync (e.g. cola)
workbench -> remote services? or others
workspace/resources -> EFS+
OS/file system -> NFS (or others, of course)
Everything above the file system can/would use a common connection
management and hopefully some common APIs for remoting, remote services,
and caching.
Scott
John Arthorne wrote:
Going back further, we had a different model again from what
eventually appeared in Eclipse 1.0. In an earlier prototype, resources
in the workspace were actually stubs for remote resources, with a UUID
stored in the resource tree that could be used to fetch remote
contents. The content of the remote resource would be lazily cached
locally as needed. There are vestiges of this prototype in the current
resource API, with methods such as IResource#isLocal/setLocal.
As Kevin points out, one of the disadvantages of this model at the
time was that it didn't interact well with external tools, since at
any given time the local resource tree on disk could be empty or only
semi-populated, and the external tools lacked the necessary hooks to
invoke the IResource#setLocal call required to make the file or
sub-tree appear in the local file system. However, there were also
other disadvantages of this model. An obvious problem was lack of
offline support. When you became unplugged from the network you could
only work with the sub-set of resources already local. Also, by making
local replication transparent there was no natural workflow for
handling synchronization conflicts when multiple parties edited their
local replicas of the remote resource concurrently. A final
disadvantage was performance. The sparse local replica model worked
great for browsing a large tree and selecting individual files to
edit. However, when it came to "batch-processing" tasks that needed to
traverse the entire tree, the entire workspace ended up being sucked
down to the client anyway. In practice, the first time the user did a
full build, or a workspace-level search, the entire remote tree had to
be made local.
For these reasons we switched to a full replication model where the
entire tree was always local, and the user performed explicit
synchronization operations to synchronize with the remote resources.
This method supports offline editing well, has good performance
characteristics, and has a clear model for handling and merging
conflicting changes. This model and some other remote development
models are summed up here:
http://www.eclipse.org/eclipse/platform-core/documents/2.0/remote-development.html.
I still think this local replication model is the best answer for a
large number of development scenarios, and I wouldn't want to see it
lost or compromised in e4. However, there are clearly several
categories of development that are not well served this model,
particularly in the areas of device development and mainframe
development. Here is one possible approach to addressing this in e4:
rather than having a local workspace tree with resource stubs
representing remote files, the entire workspace tree would reside on
the remote system. An Eclipse instance on the remote system would be
running a large portion of the traditional Eclipse "stack". Both the
workspace tree and the UI model would live in this remote instance.
The UI model would be replicated to the local workstation where it
would be rendered either in a traditional-looking client with native
widgets, or a browser (think X Windows).
My perhaps naive thinking is that it's much less expensive to
replicate the UI model than the workspace, since the UI is typically
only showing a small fraction of the workspace at any time. Tasks
requiring intensive physical resource access such as search and build
would run on the same remote machine as the workspace. This would
largely avoid having to reinvent the workspace and the massive
eco-system of existing applications built on top of it. It's true
that since Eclipse has "taken over the world" the problem of
integration with third party tools is not so great... the main
challenge now is how e4 can interoperate with the "world" of plugins
and apps built on the Eclipse 1.0 model.
John
*Kevin McGuire/Ottawa/IBM@IBMCA*
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
08/24/2008 12:22 PM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
Re: [eclipse-incubator-e4-dev] E4 towards generic
connection management (was: e4 beyond the
ongoing UI conversations...)
Thanks Brian!
Stepping back a minute:
An initial fundamental decision we made way-back-when on Eclipse was
that we'd be file system based. It seemed the best way to ensure we
could interoperate with non-Eclipse based applications, with the file
system being the one thing in common.
Personally, I'm not sure that's so compelling anymore. At the time,
it was a world where there'd be a small number of Eclipse plugins
trying to work with a huge amount of pre-existing applications. The
only way to work together is via the file system. So it was probably
the right decision then. But now that Eclipse has taken over the
world <grin>, I don't think the scenarios still match.
Today the interesting scenarios are around data sharing, data syncing,
remote access, remote computation, remote services ... that's the
current pain point of interoperability. I'm talking more than just
common shared components for the transports and services (obviously an
important pre-requisite), but rather a deep integration with what it
means to be a resource. Things like: you can't assume they're local,
you can have a tremendous number of them, maybe each IResource has
both a local storage and a remote URI, treating local storage as a
cache, keeping track of sync state, transparently accessing the
transports...
So take the Eclipse 1.0 thinking and replace "file system" with
"network". Maybe *this* is what the E4 platform needs to be.
Easier said then done though. The existing code is tied to the a file
system based resource model with many subtle assumptions which
complicate even more the problem of backwards compatibility of API and
behaviour.
Nonetheless, I do believe that a rethinking of our resource model,
with the view to remote data interop, could be the fundamental shift
for E4 and is probably what we need to do to have any kind of forward
thinking desktop presence. It is however a ton of work (Jeff McAffer
and John Arthorne will I'm sure attest to that).
Regards,
Kevin
*brian.fitzpatrick@xxxxxxxxxx*
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
08/22/2008 11:42 AM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
Re: [eclipse-incubator-e4-dev] E4 towards generic connection
management (was: e4 beyond the ongoing UI conversations...)
Hey Kevin!
Those are definitely some cool ideas!
I think using URIs to map to remote resources (or local ones even)
would give us a ton of flexibility, but would definitely present some
interesting challenges. And the whole idea of remote servers and
resources playing into a common UI for users (or multiple common UIs,
all with a similar look and feel) would fit into our discussions nicely.
A "cloud" of Eclipse plug-ins and resources all accessible through a
common UI. What a concept. :)
--Fitz
Brian Fitzpatrick
Eclipse Data Tools Platform PMC Chair
Eclipse Data Tools Platform Connectivity Team Lead
Staff Software Engineer, Sybase, Inc.
*Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>*
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
08/22/2008 09:31 AM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
Re: [eclipse-incubator-e4-dev] E4 towards generic connection
management (was: e4 beyond the ongoing UI conversations...)
Hi gang,
> I fully agree that in a world where the "Network" is becoming more
> important than the local client, a generic approach for the user to
> manage connections of all kinds will simplify user experience
> (and help reducing code duplication and bloat).
About a year ago I was looking into an area they were terming "WebOS".
The notion was that for rich applications, you need some kind of
lightweight platform pre-installed on the desktop from which you could
serve up applications written against it (presumably in JS or PHP or
whatever). One platform service was of course a communication
framework, since generally some or all of your data is going to be on
the server. This included synchronization as a first class platform
service so you can treat the local storage as a cache or offline
access. There were a number of players in this area (approx. 4-5
companies). I don't the current state.
At the time, my reaction was, "Hmm, we could be one of those!". We
essentially have all the components they talked about, though not
integrated to the same degree, and with p2 we have a first class
provisioning route.
I view this issue as being intimately tied to the flexible resource
model topic. For real data mobility, instead of assuming that
resources map to files as we do now, we should assume they map to
URIs, served up from anywhere (e.g. a MySQL database), with local
proxies providing anything from summary information (name, size),
enough say for navigation, to the full contents for editing purposes.
Current desktop services such as Search then need to be changed since
the number of resource can be huge, and searchable content could be
remote.
So this is a very different notion of "the platform" than what we have
now. A pretty cool one though!
There a more thoughts squirreled away in my brain somewhere ...
Regards,
Kevin "Not Just About Pretty UIs"
McGuire_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
------------------------------------------------------------------------
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
