examples/org.eclipse.ui.examples.job/doc/usecases.txt

Basic concurrency use cases.  Some are overlapping, but each requires
a different level of concurrency support.  Roughly ordered by perceived
implementation difficulty.  1. and 2. are currently support in Eclipse 2.1,
but we need to keep them in mind with any new story.

1. Allow decoration tasks to continue in background without affecting
   UI responsiveness or ability to modify resources.
   
   Examples:
     a) User performs a CVS update.  While CVS is computing and updating 
        new decorations in various views, the user wants to continue viewing
        and modifying resources.  Duplicate decoration work should be detected
        and avoided (don't decorate the same resource twice if possible).
     b) User is typing in an editor.  Computation of effects such as
        "red sea", and bracket matching should happen in the background
        without affecting responsiveness.

2. Very long running operations that do not modify resources, but must
   be stoppable, and joinable.
   
   Examples:
     a) User imports a JAR file.  This triggers an indexing job in the background.
        User can continue to view and modify resources while indexing happens.
        If the user deletes the JAR, or modifies it, duplicate or superfluous
        background jobs should be canceled automatically.
     b) User imports a JAR file.  This triggers an indexing job in the background.
        User then requests a type hierarchy.  Priority of any index jobs
        required by the type hierarchy should be bumped up and completed
        immediately.

3. Allow browsing during long operation

  Example:
    The user has started some long running background task (checkout,
    import, build, etc).  They want a live UI so they can browse resources
    (get children, get contents, dirty editors) while they wait for the long 
    operation to finish.
    
  Deluxe:
    The background task can complete in chunks, allowing the user to browse
    and modify resources that were involved in the operation.  I.e., they
    can edit imported resources before the import has completed.

4. Allow edit during long running read-only operations
  
  Example:
    The user starts a search.  Since searches don't modify resources,
    the user may want to modify (add, delete, change) resources while
    the search is happening.  This may or may not affect the search
    results.

5. Concurrent edit.

  Examples:
    a) The user does a CVS update on project A while project B is being deleted.
    b) The user does a CVS update on project A while that same project is
    being compiled, deleted, etc.  This is the extreme concurrency example.  

    
6. Allow preemption and restart on long-running operation.

  Examples:
  	a) The Mcq example.  User hits save on a file, and build starts.  User
  	   realizes that there is an error, and they modify and save again.
  	   They want to cancel the currently running build and start a new one.
  	b) User selects a revision in the CVS repositories view, and hits
  	   checkout.  While checkout is running, user realizes they chose
  	   the wrong version, and they want to checkout a different one instead.
  	   They want to cancel the current checkout and pre-empt with another.