This kind of message-passing architecture reminds me quite a bit of Erlang, which currently gets 9 9s of reliability in a highly concurrent, distributed production system (telephone switches). That's 99.9999999% uptime without a highly concurrent system going down due to deadlocks, live locks, race conditions, etc...
(Which reminds me of multicore...) There's been some nice work done on replicating Erlang's capabilities in Functional Java (http://functionaljava.org/) and in Scala ( http://www.scala-lang.org/). Some more information about why this is cool, along with working code (mmm; working code): http://apocalisp.wordpress.com/2008/07/28/threadless-concurrency-with-actors/(Java example) http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html (Clearer, but Scala-based example) http://debasishg.blogspot.com/2008/08/asynchronous-functional-and.html(Scala example #2) Dave Orme On Fri, Aug 22, 2008 at 10:42 AM, <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 08/22/2008 09:31 AM > Please respond to > E4 developer list <[email protected]> > > To > E4 developer list <[email protected]> > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
