Framework vs Application

Owned by Bill Branan
Jun 16, 2017
2 min read

Question: are we building a framework or an application?

Opening:

  • have always said intention is a framework that enables/accommodation of multiple types/implementations of hydra heads
  • problem that has arisen: where do you draw the line at what is in framework and what is beyond (& responsibility of different heads; code not in the framework). example: a tool that handles zooming of JP2K used in multiple heads but not in core hydra-head, so let that be something we use, but not included in the code.  lots of grey areas.
  • example: Drupal is a framework for building applications, Rails is also a framework for building applications.  
    • Rails: strong foundation for buiding an app from scratch, but make no assumptions about users, their data, or interfaces (left open ended).  
    • Drupal (contrast): has notions of UI, data, etc. provides basic tooling for achieving within their context; more of the stack handled by the framework & people get up to speed much quicker, but reduces flexibility for repurposing code/reimagining the space
    • there is no out of the box Rails app for kicking the tires, but there is for Drupal.  What would/should work for Hydra?

Discussion:

  • One flaw in Hydrangea: we knew it was for OA, people tried to make it something it wasn't; should we have a be all & end all hydra-head sample, or make a lot of little different examples.
  • Concerns with application development vs framework development: upgrade path problems, user support problems. Doesn't mean out of the box apps are bad, but is it setting unreasonable expectations? 
  • Concrete example of difference: Basecamp as Rails app - couldn't download Basecamp but could download Rails and build a clone.  Community fins solutions, and those solutions don't have to be part of maintained core.
  • Jonathan: always thought framework was the way we were going; others noted some confusions.  Applications exist as separate projects, even with their own communities? Then what is the relationship between core framework and the organization.
  • Hydra has always had definitions and models that are recommended, for the sake of interoperability.  Does/should a framework care about view-level stuff?
  • Raise the issue of introducing the "product" in the library/higher-ed/GLAM space...are most people expecting applications, and should we be focused on them or others (more tech-enabled)?
  • Remember the question of why Hydra vs Islandora (or Drupal); we don't want to be in competition
  • If we build a framework, then make a demo and one demo only  (discussion of using demo versions of existing production apps) 
  • People need to see things, but if we have a project-managed demo app, then we have Hydrangea again
  • Most institutions already want a sandbox of their own apps (dev to test to production is what most have now -- add a sandbox at the production level)

Answer: we still do want to focus on framework, not application. institutions can spin up sandbox instances of production applications. (UVa will do this with next Libra build: we will will get a sandbox in place that will be the production build, wiped of data each night)