Doug,
I don't agree with the statement that Team providers should use a native tool to bootstrap your Eclipse workspace (i.e. you used the phrase "how team systems should work"). I think that the user should have the option to use the native tool if they so choose but I think that many users appreciate being able to setup their Eclipse workspaces using checkout (load, etc) wizards integrated in Eclipse (i.e. I can't imagine what life would be like if I had to use the CVS or SVN command line clients to checkout projects from those repositories and then import them into Eclipse).
Or were you describing this from the standpoint of a desirable architecture for a repository provider implementation were a native client is used for the operations on the local file system and the integration in Eclipse is handled through a layer on top of that that makes any changes on the local file system known to the Project layer so it can be passed on to the application layer? I know this is done in many cases but does have drawbacks, mostly related to responsiveness of the UI during long operations (e.g. progress reporting, cancellation, resource deltas).
Michael
On Thu, Oct 2, 2008 at 8:18 PM, Schaefer, Doug
<Doug.Schaefer@xxxxxxxxxxxxx> 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.
Also at tomorrow's
meeting we should discuss if we want to continue our discussions on the
platform-core-dev list, or move them to the e4-dev list. My opinion is changing
on this. I'd like to get concensus from the team on how we want to do
this.
Cheers,
Doug.
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
