Re: [platform-core-dev] Re: IResource outside the workspace

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

More responses below...

Bob Foster wrote on 28/07/2005 02:00:58 PM:
> 
> But I do agree. People (who don't have a Smalltalk background) want
to 
> use files in the file system. They don't want any restrictions about
> where those files are. They don't want products filling up their folders
> with metadata, refusing to work except on "blessed" folders,
telling 
> them where they can create folders, or any of the other restrictions
> Eclipse has.
> 
> Yes, Eclipse is wildly popular. People will take the bitter with the
> sweet. But why leave the bitter in if it's not necessary to solve
the 
> problem?

It keeps us employed, alternately removing and adding
bitterness with each release ;)

> 
> A project is just a folder with some associated metadata. It doesn't
> need to be in a special location. The metadata doesn't need to be
stored 
> in the project folder.

True. In fact, metadata wasn't stored in the project
folder in Eclipse 1.0. However, people wanted it there so that when the
project was transferred to another workspace, either via repository or
zipping and emailing to a friend, it wouldn't be lost and require recreating.
 Here's the design doc that proposed the change:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/rfc/0006/index.html

> The current workspace serves two functions; it
is used to store metadata 
> for a collection of projects and it is used as the root folder for
> projects. The latter is an unnecessary restriction. The location of
> project folders is part of the metadata.

The latter isn't even a restriction. If you don't
choose your own location in the project wizard, the workspace location
is just used as the default.  However, you have always been able to
store each project in a different location on disk, separate from other
metadata, if desired. There is a danger of confusing the "workspace"
directory on disk with the IWorkspace and IResource API.  The "workspace"
directory is actually defined by the base Eclipse runtime (which calls
it the "platform instance data area" just to add confusion),
and its default name is more of an historical artifact.

> 
> I can't quite see the picture that Ed has in his mind. If it's a 
> Navigator view with C, D, E and F drives at the top level, I don't
agree 
> with it. An IDE needs to focus. Users really don't want you to search
> their entire file systems. If, however, it's a view containing 
> user-selected folders that they have chosen to designate as projects
of 
> one type or another (or multiple types), that sounds about right to
me.

This also roughly sounds like what we have now...

> 
> To respond to this requirement, Eclipse is slowly eking out little
> tweaks that liberalize file system access. Linked projects, folders,
> files. File > Open File. But these little changes are either too
small 
> to make much practical difference or, as in the case of Open File,
leave 
> broken API and dangling end cases in their wake. IResource now stands
as 
> the great divide between Eclipse-based products and RCP. Maybe it's
time 
> to go after the real problem.
> 

When the split was made between RCP and IDE portions
of the platform, IResource was actually explicitly chosen as the dividing
line. Many RCP apps don't have any user files that they operate on.  Those
that do often don't need things like projects, builders, markers, and other
IDE-like concepts attached to IResource.  And if they want that stuff,
they can always add org.eclipse.core.resources to an RCP app.  I must
admit that by throwing RCP into the conversation you've lost me about what
the "real problem" is...

John