-
Notifications
You must be signed in to change notification settings - Fork 71
November 18, 2015
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:
- Time: 1:00pm Eastern Daylight Time US (UTC-4)
- Dial-in Number: (641) 715-3570
- Participant Code: 304589#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #islandora on irc.freenode.net
- Danny Lamb
- Melissa Anez
- Diego Pino
- Nick Ruest
- Jared Whiklo ⭐
- Nigel Banks
- Donald Moses
- Kelli Babcock
- Brad Spry
- Sprint debrief
- Continuing the derivative discussion
- Discuss: rdf namespaces and properties: dc, dcterms, schema.org and DPLA alignment
- Adopting the upcoming D8 release literally the day after the meeting
- Project planning. What are our priorities if:
- We had funding to develop CLAW
- We had a developer's exclusive time (say, six months)
- Installation woes
Did a bit of jumping around the agenda, so be prepared.
Sprint last two weeks, focused on knowledge sharing and documentation. Issues completed for
Documentation is a lot better than before and is up-to-date on mkdocs. Any suggestions on better organization or anything to make it readable/usable, please put in an issue.
User documentation has lots of new stuff from Donald and Melissa.
There are some tasks that Donald got assigned that he didn't complete, should he continue working them or wait for the next sprint. Consensus is, if you want to and have time. Go for it!
Pull request #111: goal was to index Drupal content into the triplestore. This required karaf 4 and that change broke multi-part messaging for the Basic Image Service. Danny switched to use Apache CXF for the endpoints. Verifying/testing this PR has exposed issues in installing, most prominent on Linux boxes. But has appeared on other OSes. Nick was missing fcrepo-camel-toolbox which he has added, could be part of the issue. Danny thinks it's weird how we feed the scripts into karaf, which could be causing some problems. Also Karaf seems to die when booting randomly. Working it through and making progress.
Issue #69: Idea is to show people how the routes interact, but it is quite messy. Stack diagram is a work in progress. Diego attached his work to the issue so you can see it and edit it (yED) yourself. Second version will be more abstract with basic workflow and less detail for now. Service description are missing and only ingest workflow is only done for images.
Game plan is a sprint once a month. Tentatively Dec 7-18. In the next sprint, should we focus on one particular part. Diego: Drupal side or Camel side? Focus on one or the other. Focus on the Drupal side, work towards having RDF coming out. Danny: Focus on a goal (ie. modelling content in Drupal) and it will touch both sides, but have that as a goal.
Still 36 open issues to work on, so plenty to choose from.
Do we work towards Drupal 8 for the next sprint? Consensus that we should talk about it.
Nigel, Donald likes Drupal 8 for next sprint.
Melissa: We need to send that decision up the line for approval.
Danny: Likes it, but it is a rush release of D8.
Donald: We need to determine what we need that is/isn't in D8
Danny: One thing that is missing is the XPath Field module. Do we port it ourselves or aim to use Entities and leave XML behind. It could be better long term to design it as PCDM entities linked together, which means we don't really require XPath Field.
Diego: Create base entity that requires RDF and then have dependant entities to build on it. Drupal 8 is basically Symphony 2. So our choice of code grows. Also a concern that with the release Drupal 7 modules might move to D8 and the older versions might lose maintainers.
Donald: Storage is important, does Drupal 8 offer advantages there. Store all Drupal 8 content in Fedora, to avoid syncing back and forth.
Danny: This is the issue. How do we deal with the question of using Fedora as the centre of the stack versus why do we serve thumbnails from Fedora when its so slow. Hard to say whether we should store everything in Fedora or not.
Nick: This brings up the question of clustering. Should we wait for the Fedora Performance/Scaling WG to reach it's conclusions?
Danny: We will probably be doing alot of that testing ourselves anyways.
Diego: If we have 2 Drupal front-ends from one Fedora, then 1 should be a consumer only.
Danny: Perhaps break the work chunks down, allow for more workflows. ie. Ingest Tiff to Fedora which makes a thumbnail. Which is ingested into Fedora and kicks off a separate workflow for thumbnails.
Melissa: Decision on moving to Drupal 8 needs to go to (Roadmap Committee?, Board of Directors?) for approval. We are funded as a Fedora 4/Drupal 7 project.
Diego sent message out to community, this is important to the community. Wait 1 or 2 weeks and see what people respond, then move it up.
Board of Directors meeting is next week and possibly Nick have to report on CLAW.
Danny: Now that Drupal 8 is "released", it lends more credibility to the thought/plan to move towards it.
Donald: I like to go with the evidence. What are the reasons to move? What do we gain and what do we lose.
Nigel: Not having to re-do the work we are doing now in only a couple months and you get the better practices in PHP. Also, Islandora has a community made up of more PHP developers than Java developers. Makes it easier to get adoption.
Diego: I have a love/hate with Karaf/Camel, seeing the difficulties for people to jump in to the new stack and we need more developers. Bringing in existing Islandora developers by sticking with PHP more than Java.
Danny: All I'm trying to get from Camel is to handle the messaging sanely. Exposed REST endpoints are an afterthought and proving to be troubling.
Focus for next sprint?
Danny: PHP Services. Doesn't affect a move to Drupal 8. Then if we goto Drupal 8 we can make the changes at that point.
PHP Services description: Have the majority of RESTful services pulled out of the CMS context and exposed so that Drupal hooks or Event system we can interact with them. CRUD operations on PCDM objects and object types. There are lots of different ways to do this, but the core idea is making this a separate layer.
Are the services a wrapper like Tuque, or only dealing with RDF, or like PHP micro services?
Yes, like micro services. Silex or Slim or Phalcon something like that. Makes Islandora Core a REST API and makes the Fedora API more understandable, it might expand on the Fedora API. Also the micro services will be dealing with PCDM Objects.
What about Chullo?
Chullo will be the heart of the micro services. If everything is written properly the code reuse will allow for individual services to be a thin layer to expose the Chullo code in a particular context.
Consensus to work on PHP services for next sprint.
There is a Funding Working Group on the board, we need more project outline details to allow for discreet goals, etc. For a developer if we have funds to hire. Also for applying to a grant funding organizations.
Danny: Everything we have spoke about, because they are all interconnected. Pick one.
Top 4 goals
- PHP services
- Drupal triplestore
- Properly contextualize JSON+LD in document store
- Need to create some sort of business rules system, for generating derivatives so mildly technical people can do that with out changing code. (ie. Drupal Rules, Drools, or Roll-our-own Rule Engine (could be RDF<->JSON))
Is there a deadline for this information?
Some grant deadlines are coming up in Jan/Feb. So no immediate deadline, but sooner is better.
What will a solution pack be in CLAW, related to custom entities, and services and whether we stay D7 or go D8.
To be continued next week...
Fedora 4 Interest Group call is cancelled for November and probably December. Thought about replacing that call with this call, but thought the time can be used to discuss more high level things.
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap