Skip to content
kim pham edited this page Apr 19, 2017 · 6 revisions

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

Attendees

  • Nick Ruest
  • Dan Davis
  • Diego Pino
  • Natkeeran Ledchumykanthan
  • Adam Soroka
  • Danny Lamb
  • Kim Pham ⭐
  • Jared Whiklo
  • Aaron Coburn
  • Jonathan Green
  • Martin Dow
  • Robert Waltz
  • Ed Fugikawa
  • Bryan Brown

Agenda

  1. Spike for visibility?
  2. https://github.com/Islandora-CLAW/CLAW/issues/603
  3. Using stock Content Entities

Minutes

Danny: Trying to move over to YAML configuration, want to discuss how we're going to do it. Issues - we want to use YAML (addressed), Symfony configuration component (not addressed), how we're going to bootstrap the applications and what if anything should be shared btw microservices

Jared: Config around interface, maybe go around lightweight provider, see comments from Jongreen. This works, propose go with it. What do we want out of these microservices? How small should they be? How should they operate, do people want to build things on top?

Danny: Do we use a service provider for multiple services is not a particular problem. Does each microservice need to be boostrapped independently of one another - yes.

Diego: Question is what we want for our own projects. Bootstrapping and order to do things vs Silex, Symfony. Define a container but you don't bootstrap, you add a service. Put service provider inside service provider you'd lose control.

Jongreen: Shouldn't be an issue, in crayfish commons you pass a closure that has inside it a configuration, register a closure. Drupal does this, bootstraps hundred services before you get the container.

Diego: But you can't swap service providers

Jongreen: we don't, already registered but not instantiated until someone uses it. can be replaced. until such a time when someone needs it. configuration can be replaced for a service provider.

Jared: in islandora service provider we use things like monolog functions. you can replace this as long as you replace with another logger. like the idea of not having to instantiate all these things. wonder if we'd start build a monolith

Danny: If you don't use monolog you register your other thing and re-register to use your other thing that's not monolog

Jongreen: loading up container with services doesn't harm a whole lot because it's not instantiated until your microservice uses it. Service won't get loaded if not used. e.g. a fedora resource loader will live in the container, would be lazy loaded.

Jared: Concern with swapping out one logging service with another. if there's a way to do that that's not onerous, don't have a problem with registering services within services. like configuration defaults

Danny: if we can deploy & load own configuration independently without relying on another one we'd be OK

Jared: what's implemented will make sure follows psr-3 spec, yaml config service provider will allow setting the name, but code assumes you're using crayfish. errors if not using crayfish as basename. look at config interface and set defaults in that sense or stick with this

ruebot: what should we do with issue 603?

Danny: if someone would go ahead and do the work to do something athat provides default values

ruebot: https://github.com/Islandora-CLAW/CLAW/issues/603 assigned to Aaron, working on it on Monday

Spike for visibility?

ajs6f: Any interest in a 'spike' for functionality, would be helpful to show something like Islandora Scholar working - a curated walkthrough or video that shows you what it would look like in CLAW.

Danny: In current incarnation Scholar does not yet exist, but will demo features of MVP for islandora conference

ruebot: MVP focusing on images microservices, backend piping, close to finishing. then we will start looking at other use cases and community sprints

Using stock Content Entities

Danny: Still a little early to talk about this. Will have to work on multiple different types of content entities. We work on our own, then there's media. Scholar would have user entities, and then we'd need to work on flushing Drupal users back to fedora as well. If we work with content entities that we're not in control of like media or users, this will drastically cut code if we use node vs custom content entities we've made. To discuss again in the future.

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally