[
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...)
|
Hi Kevin, Jeff, and all,
Some thoughts about Kevin's very interesting posting.
Although network distribution at the file system layer (i.e. EFS or VFS
or NFS, etc) is a good approach, I would argue that it's not the only
way...and sometimes not the right way...to do distribution. For some
components, it makes more sense to distribute and/or or replicate the
component-specific model (or pieces of model), and do model
synchronization in an application specific way, rather than distributing
without application knowledge (i.e. at the level of resources...files
and folders, only) and synchronizing in a generic way (i.e. via
transactions). With component-level knowledge, components can control
things like replication strategies, model synchronization, network
failure handling, and performance...and I would assert that sometimes
they need to control these things (depending upon the app's
requirements). As a simple example, ECF's real-time shared editing does
these things...i.e. it replicates the IDocument, and then applies a
synchronization algorithm (cola) to deal with asynchronous state changes
(aka typing :).
Happily, things like the OSGi service layer, along with remote services,
allow for the creation of a variety of local and/or remote
abstractions...in addition to networked file systems. I think that
having several ways of doing network distribution (virtual file systems,
but also remote services, component-specific communication) are all
going to be needed (and desired) for E4. So I might modify Kevin's
thought just slightly...in the following way:
>So take the Eclipse 1.0 thinking and add "network" to "file system".
Maybe *this* is what the E4 platform needs to be.
In any case, returning to the original set of thoughts for this thread,
I still believe/agree that having generic connection management makes sense.
Scott
Jeff McAffer wrote:
Yup. its a lot of work. Good news however is that John has done a
lot of separation with EFS. there will still be a lot of assumptions
and expectations to work though. Fundamentaly you have to give people
some structure to work with. When you start mixing in more and more
different systems that common API/model becomes harder and harder (or
it becomes less and less). Its a balancing act. As Kevin points out,
it is definitely worth reviewing. The world has moved quite a bit
since the original work on the Eclipse resource model was put in place
(that work was done well before Eclipse).
Jeff
Kevin McGuire wrote:
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
