You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

iPlant Goals & Objectives

What is the community?

  • resource providers (where resources are domain resources & tools)
    • ease of user management (SSO, ease of enrollment/registration)
    • ease of group management (inherit across providers; must align with user mgmt)
    • data access across providers (iRODS)
    • manage /quota/access at various levels (meter and throttle)
    • resource and services "federation" (sharability of workflow between services)
    • integration of 3rd party tools
  • end-users / consumers (domain scientists)
    • SSO, linked to home institution
    • ability to form ad-hoc groups
    • ability to control access with keys/tokens that can be honored across services and providers, and yet limited based on time or something
    • can use web/API and command line apps w/ VO-based credentials (command-line apps where different libraries can be pulled in, can do more than just ssh)
    • keep data in one location, integration with many analysis platforms
    • activity dashboard, messaging and alerts, consolidated from providers
  • misc notes
    • using google for calendar, document creation (wiki for final doc, but for the actual drafting, they go to google); use doodle for meeting scheduling
    • iPlant does not have grouper installed
  • developers
    • user mgmt out of the box
    • access to federated resources
    • ability to meter and throttle (because developers easily create DOS situations; need handles in place so they know who is doing what)
    • unified sharing, reporting, dashboards
    • ease of integration to resources that need significant permissions (i.e. running compute data intensive tasks)
    • become part of a "market place" model
  • educators (classroom, workshops)
  • No labels