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
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.
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
|
