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

[brian.fitzpatrick@xxxxxxxxxx]

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