1 / 8

User Isolation vs. Layered Workspaces

User Isolation vs. Layered Workspaces. Basic Ideas. Workspace Concept. Content from “inactive” and “active” workspace are shared between all users of the Dev-Config Files that are “checked out” are specific to a client-spec (i.e. user). Basic Ideas. User isolation Concept.

kesler
Télécharger la présentation

User Isolation vs. Layered Workspaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. User Isolation vs. Layered Workspaces

  2. Basic Ideas • Workspace Concept • Content from “inactive” and “active” workspace are shared between all users of the Dev-Config • Files that are “checked out” are specific to a client-spec (i.e. user)

  3. Basic Ideas • User isolation Concept User “Bill”/ Cfg “B” User “Uli”/ Cfg “U” User “Bill”/ Cfg “A” User Work Area P2 V10 P3 V4 P9 V4 P2 V9 P2 V8 P1 V1 P1 V1 Partition Sharing via multiple references Partition Pool P1 V1 P9 V4 P2 V8 P2 V9 P2 V10 P3 V4 • Each user has his own “file system” for each dev-config • User selects what is visible to him via normal “sync”, “check-out”, “remove-from-client”, … • Versions of partitions that are synced by multiple users exist only once • Unreferenced partitions are removed from partition pool

  4. Layered Workspaces • Strengths • Significant design and implementation efforts already done • Effort for integration tests of modelers are reduced because changes are visible to all users immediately after “check-in” (like after “activate” in R/3) • Minimizes server impact (database space and memory) • Weaknesses • Tasks that require a stable environment cannot be performed • Re-Implementation of DTR security for access of shared partitions

  5. User Isolation • Strengths • Users can perform modeling tasks without being bothered by their colleagues that perform “check-ins” or “activates” • Usage concept equal to Eclipse • Sync of active/inactive content is explicit decision of the user • Users do not have to understand what “client-specs” are • Users can sync any revisions (from active or inactive) that they need • Built-In security by NWDI, because sync is explicit user interaction • Weaknesses • Implications on MOIN not yet evaluated • More data on the server because each user could have different versions of the same partition

  6. Combine The Best Of Both Worlds!

  7. Basic Ideas • Combined Concept (Workspaces + User Isolation + Partition Pool) • Client specific workspaces can be used to sync partitions from “inactive” • Users can stay with these versions as long as they need • Other partitions that are not synced to “client” are still updated immediately • “Remaining” partitions from “inactive” • All partitions from “active” • The “Partition Pool Concept” is used for all “Client Specific Workspaces” to avoid duplicate partitions

  8. Combined Concept (Workspaces + Isolation + Pooling) • Strengths • Users can perform modeling tasks without being bothered by their colleagues that perform “check-ins” or “activates” • Partitions from “active” are always up-to-date • Combines advantages from both worlds for users • Step-by-Step implementation possible • First implement the “sync-to-revision” concept • Then optimize by implementing the “pool” concept • Weaknesses • Combines complexities of both concepts for MOIN implementation • More data on the server because each user could have different versions of the same partition • Re-Implementation of DTR security for access of shared partitions

More Related