they are technically gems that are added to hydra application
one plugin per content type
enhances func. of existing content type
Ex: Atrium: developed on top of BL--how does it integrate? Have it fully functional by fall of this year.

Don't use — moot point because R3 has moved away from plugins and more towards gems

expectations from developers to produce API-type framework
reverse-engineered from SALT?
decide on what the API should be
- libraries that aren't hydra-related, ex. FTK code that doesn't have anything to do with Hydra
making assumptions about BL behavior and its presence in the application stack
- lots of potential benefits
- facets – could you de-couple them?
is there too much dependency on Solr as well as BL?
- loose a lot of power if you abandon them
- don't have to reinvent the technologies
  
  the more you take for granted, the further you can go
moving element from implementations to the Hydra core
- distill elements of Hypatia as part of a move towards an API
institutions that already have content have already made decisions that can be pulled in

All these features exist in other hydra implementations and could become plugins on their own

image management
- set of featured images, or image collection
- derivative images
- cropping images from j2k images
- j2k viewer
ID management
- super-user permissions
- users/groups
- apo code
- hierarchical permissions and roles
- authorization and authentication
collection building (not just image-related)
metadata editing
media players
batch ingest — instructions only; not possible to code because of all the variations

Browser not supported