Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-incubator-e4-dev] Straw man proposal

> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 
> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On 
> Behalf Of Patrick Mueller
> Sent: Friday, October 03, 2008 10:56 AM
> To: E4 developer list
> Subject: Re: [eclipse-incubator-e4-dev] Straw man proposal
> On Oct 2, 2008, at 8:18 PM, Schaefer, Doug wrote:
> > Hey gang,
> >
> > To feed the discussion for tomorrow's resource meeting, I have put 
> > together a straw man proposal for the e4 resource system 
> architecture. 
> > I'm sure it has a lot of holes and I'm hoping you'll help me fill 
> > them. I could also be totally on the wrong track and maybe there's 
> > better answers we can put on the table. But let's discuss.
> >
> > The proposal is here:
> Since we have intentions of running bits of eclipse on the 
> web - "We need an advanced Java editor that can run both on 
> the desktop and the web" (Steve Northover, this list, 
> 2008/09/19) - then as we talk about "resources" we should be 
> talking about the web model for the resources as well.
> For instance, if we imagine a RESTy architecture for this 
> (I'd suggest this as the first pass), then we need to talk 
> about the resources (things on the server), the 
> representations of those resources (bytes the clients see: 
> source code, modelled views of source, etc), the URLs of 
> those resource representations, and the HTTP verbs that are supported.
> Some thoughts from Henry Story related to this (web and IDEs anyway),
> here:
> pment_environments

I agree. And that is the advantage of leveraging the work started with
EFS. It already is URI based and we just need to extend that to also do
the more physical file system things we need to do to support other
tools that need that level of integration.


Back to the top