Tripal User's Meeting 2018/09/07

Meeting Date
Attendees

Stephen Ficklin, Shawna Spoor, WSU

Lacey Sanderson, USASK

Andrew Farmer, LIS

Meg Staton, UTK

Abdullah Almsaeed, UTK

Bradford Condon, UTK

Sook Jung, WSU

Sean Buehler, UConn

Blake Inderski, USDA-ARS

Ethy Cannon, ISU

 

  1. Tripal v3.0 full release imminent!  -- just working on some last minute fixes and testing.

  2. Future of Tripal Discussion

    1. Andrew Farmer:

      1. Would like to continue to integrate with Tripal community and co-ordinate and co-develop and use what others develop.

      2. Faced with the problem: don't want to build websites that are tied into a single framework technology.

    2. Ethy Cannon

      1. Some sites have very little resources (few developers).  But don't have time to learn Drupal 8/Tripal 3.  

      2. Lacking developer capacity makes people reliant on Tripal community to help build tools.  

      3. Worried Tripal is getting locked into old technologies in being tied with Drupal

      4. Main developers of Tripal are extremely skilled with Drupal but for those without those skills it can be very challenging.  Especially or adding customizations.

      5. Drupal should be easier to integrate with non Drupal technology.

      6. Worried that being tied with a 3rd party framework you are at the mercy of what those developers do?

        1. Bradford:  We are always stuck with some framework

        2. Andrew:  We want to adopt what was developed and piece together what works.  Not only don’t want to be tied to a single framework, they often don’t have that luxury

        3. Ethy:  Having a website built inside of a monolithic framework that doesn't easily support integration with other tools is a problem.

        4. Meg:  Working with a single framework is it helps manage permissions, and easier to manage cross site-searching.  Having multiple components all strung together complicates systems administration.

          1. Andrew: containers may be able to help with this.

          2. Lacey:  also want to provide a consistent user experience. I believe this is key for users being able to learn/navigate a given resource. The user shouldn’t need to care about there being different pieces underneath the website -searching and navigating should be seamless

          3. Andrew:  a consistent user experience may not be as important for users who have to use multiple sites, because switching across sites causes inconsistent user experience.

    3. Sook asks Andrew about his experience

      1. Phylotree viewer and expression work that integrates with Tripal

      2. Genome Context Viewer: JavaScript / Python -- developers are talented in those skill sets.  He doesn't think it's a good use of their time to relearn Drupal/PHP when they are skilled in technologies that can already work.

    4. Bradford: What is Tripal?

      1. Chado + Drupal = Tripal… To make Tripal platform agnostic may be more than our group can handle. He thinks if we change it would be a framework change.

      2. Ethy:  Chado is a difficult schema to work with.  Tripal should be driving Chado and defining how data is mapped into Chado.  She's interested in an approach that allows Tripal to provide functions to Chado but allow for other technologies (including Drupal)

      3. Meg:  Anthony wrote a Python loader for Chado

      4. Bradford:  Is understanding Ethy's desire to decouple the Chado integration from the Drupal code.   He agrees that Tripal does bring a common interface to Chado. The perception is that Tripal is an API to Chado.  

      5. Meg:  It is doable to separate out Chado code as a "library".  Do we want a "headless" Drupal or a lower-level library that decouples Tripal from Drupal.

      6. Bradford:  Are we trying to move away from Chado?  (consensus is no).

      7. Andrew:  A service layer may be good enough.  

      8. Bradford:  object with this may be that if he writes a module he can now only share the Tripal part and not the Drupal part.  Decoupling the code may limit how much we can share.  Would decoupling create more work to maintain?

        1. Ethy:  if the framework uses the tool then you take the framework with it.  If you bring in lots of different tools with you have to manage all those tools.

        2. Lacey:  It's harder to collaborate with others if everyone has different approaches with different frameworks.

    5. Do Tripal  v3 web services provide the ability to decouple?

      1. Stephen: too slow at this point, need to improve performance

      2. Lacey: can’t post data through web services

    6. Thoughts:

      1. Lacey: wants to stay with Drupal and does not want to re-write site in another platform.  But she is warming to the idea of that Tripal could be used without needing to work in Drupal.  That may help with learning curves because it keeps people out of Drupal-land. But it is not a full decoupling.  

        1. Ethy:  will be difficult to move away from PHP (she would like to learn a new language, however).  

      2. Stephen:  In a conversation with Dorrie she indicated she wants Tripal to stay with Drupal.  

        1. Sook:  would be too difficult to leave Drupal because of all the infrastructure already built.

    7. Stephens proposal:

      1. Break Tripal in ½: that related to data storage into a PHP library and then maintain the Drupal module for the front-facing and integration

      2. We need our community! We need to support flexibility to keep our community.

      3. But we also need the common language and framework for when we are between or low in funding. We need to share modules and development effort.

    8. Lacey: focus how to make Tripal to truly integrate 3rd Party software.  (i.e JBrowse, Django, etc.) How to have a consistent interface.

      1. Ethy agrees (150%).

    9. Lacey: regarding switching languages or frameworks just to chase what is most popular should be considered heavily. We cannot switch from language to language over time.

    10. Lacey's Proposal:  Take existing classes for Tripal v3 and use those to form the basis of a PHP Tripal library.  Then when we move to Drupal 8 it may make the upgrade easier. It can still provide a middle layer that folks can learn and avoid the Drupal layer.  Lacey loves what Drupal allows you to do despite its difficulties.

    11. Lacey:  would a Tripal PHP library help with development in your group, Andrew?

      1. Andrew:  Language is important.  What is built into the language is important.  The Tripal and Chado loaders don't behave the same way.  Anthony has had issues with the PHP loader and so he created the Python loader.  His group is not excited about PHP. He's not sure a PHP library would increase the utilization of it.  

      2. Ethy:  If we do a middle or sub-layer it should be in an object oriented language and PHP is not object oriented. It's object-capable.   It can cause trouble. She thinks it's not safe.

    12. Discussion about using python for the middle layer

      1. Ethy: feels it’s sufficiently close to PHP to make learning it easier for PHP guru

      2. Lacey: worried about how do we actually integrate between python and PHP. If this is done with web services, I worry about performance. Is there an alternative to make the integration of php

        1. Looks like PHP+Python is not a new concept, for example: https://www.csh.rit.edu/~jon/projects/pip/

      3. Stephen: provides closer integration with python groups (e.g. Anthony’s group, Andrew’s group). Closer integration perhaps with the galaxy community. There might be some help from Andrew’s group for such an endeavour

      4. Bradford: perhaps we should be talking about wrapping the PHP for use by python users. Similar to Anthony’s work

        1. Reason being: the core tripal people use and enjoy PHP

        2. We shouldn't switch languages to appeal to people on a “if you build it they will come” philosophy

      5. Main counterpoint: PHP is not great with object oriented.

        1. PHP does not enforce standard object oriented rules: too loosely typed. This causes issues with inheritance

      6. Steve:  maybe not so much a focus on object oriented but more with the monolithic approach to Drupal where it's not clear “what to do where” in development.

      7. Bradford:  MVC

      8. Andrew: has heard good things about newer PHP frameworks.

      9. Lacey would prefer that we stick with PHP because it is easiest to maintain what we already have. If we feel OO capabilities are sufficient then let's stick with PHP.

      10. Bradford: he feels the scientific community is more interested in learning Python.

        1. Specifically they are biologists and can use python down the road for scientific computing, less so for PHP.  Similar to Andrew’s comment below.

      11. Andrew:  A small non-profit organization and so folks float between different tasks that are not just focused on web development.  Python seems to cross multiple domains.

        1. Ethy:  informatics students are typically working in Python.  There is no reason an informatics student shouldn't be writing modules for Tripal and if that's their language we should accommodate.

    13. Bradford:  If we are leaning towards a middle layer Tripal. Does really satisfy the issues we're facing?

    14. Ethy: whatever we decide to do, we should do a proof of concept to see if it works before we jump in wholesale.  Lacey especially agrees.

      1. Stephen:  proof of concept:  move GFF to middle layer

      2. Ethy:  have these type of activities at our annual hackathon.

      3. Lacey:  better POC would be modeling entities/fields in the middle layer and get Drupal to render it.  Expose only one type of data type and it's fields.

      4. Let's do POC with Drupal 8.

 

What would the Proof of Concept look like:

  1. Tripal Middle Layer

    1. Language: Python.

    2. Abstracts communication with data storage

      1. Provides a Chado layer

    3. Provides some sort of service for use with Drupal

    4. Use Case:

      1. Provides Entities/Fields for a gene.

      2. Easier for researchers who might prefer Python to write modules.

      3. Supports those who want to stay in Drupal without impeding their ability to maintain their sites.

  2. Tripal Drupal 8 Module

    1. Consumes the services from the Tripal layer.

    2. A PHP wrapper for existing API

 

Timeline

Sept 17th: call to form a group of folks who want to work on POC.

November 15th:  revisit and see how it's going.

January 2019 PAG hackathon would be to implement Tripal 4 based on results on the proof of concept.