Re: [eclipse-incubator-e4-dev] E4 towards generic connection management

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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