Skip to content

2024 05 13 Edirom Developer Meeting

Jump to bottom Edit New page
krHERO edited this page Nov 26, 2024 · 1 revision

TOPICS

13.–15.5.2024, HNI Paderborn, first edirom developer workshop (organized by Edirom-Online reloaded project)

general topics

  • present status and general plans of the project Edirom-Online reloaded
  • licensing, eg MIT, GPL, suggestion by us for newly developed

techstack 

  • frontend 
  • backend
  • big topic: extJS 
  • web components

organizational

  • think about what is the best way to do project-specific extensions/modifications, PLUS role of the core code (edirom reloaded project aims to work on modularization)
  • project management in github (structure, open issues etc.)
    • labels

PARTICIPANTS

monday afternoon: DanielJ, DanielR, Hizkiel, Kristin, Benjamin, Niko, Alex, Silke, DennisF, Peter

tuesday morning: DanielR, DanielJ, Benjamin, Niko, Hizkiel Alexander, DennisF, Silke, Kristin, Peter, Tobias (remote)

tuesday afternoon: DanielR, Hizkiel, DanielJ, Benjamin, Niko, DennisF, Silke, Alexander, Kristin, Johannes (arriving 15h), Tobias (remote)

wednesday morning: DanielR, DanielJ, Hizkiel, Nico, Peter, DennisF, Silke, Kristin, Tobias and Stefan (remote)

AGENDA AND MINUTES

General discussion

  • we have two “requirements”: deal with old edirom (keep edition “alive”) but “reload” a new edirom with new functionalities (e.g. WP 1.3 touch capability: not implementable for old edirom) and update software in general, e.g. decision to rewrite or “only” update Ext JS is not taken yet → general idea, to keep edirom alive the whole time (web components work in the old edirom)
  • one possible way: stay with current code and update it
    • create parallel branch with separation of frontend from backend (with all XQuerys)
    • make web components while delete functionalities that are inside that branch
    • update Ext JS

Licensing

  • at the moment GPL license, not as open as possible, you have to go on with GPL use with further development
    • GPL: it forces us (the original owner of edirom is also us) all to do project-specific code under a GPL license, publish it and bring it back to the original repository
    • assumption: as owners we “should” be allowed to change licenses at our own code
    • what about licenses of published releases
  • software from external developers (eg “Bezahlschranke”) should not be a problem, since it is not a part of the edirom software itself 
  • two ideas: stay with GPL in the old edirom, but use MIT license for new code vs stay with GPL also for new edirom
  • ACTION: do more research about licenses and decide at a future community meeting, especially: put closed software into GPL, switch from GPL to MIT → we can not make a decision today
  • Benni (via slack): bzgl. Lizenz der Edirom Online – Sencha ist da sehr eindeutig (https://www.sencha.com/legal/open-source-faq/) Wenn man die GPL Version von ExtJS benutzt, dann muss man open source unter GPL veröffentlichen.

Backend

  • decision to split frontend and backend is already made for the future
  • in the old edirom: XQuerys have some exist-specific stuff in it
  • generic backend with generic XQuerys, plus database-specific layer (e.g. exist-layer if an exist-database is used)
  • XML-database is not the only possibility for future edirom, but edirom has to deal with XML-code (MEI, TEI)
  • ACTION: we need a clear definition what should be inside an API and how to send data
  • current edirom: preferences-file in the data package for project-specific information (also XQuerys inside)

Web components

  • combination of javascript-file for functionality and custom elements in html
  • advantage
    • capsules functions, e.g. single views 
    • can be very simple, but frameworks in the background can be added
  • idea: a component for each functionality, be able to use this web components also flexible and independent from a whole edirom (e.g. also as a part of a website)
  • since web components can contain web components, the whole edirom could be a web component
  • interaction of components forces us to be very clear 
  • every component has its own controls; plus we can have a bigger component with controls containing other components; OR we can have a bigger picture added with a Konkordanznavigator as a single web component
  • the web component does not have to know about the situation outside
  • web components: video, audio, image, music, layer-container, neutral annotations (measure, SVG etc.) can be added semantically by labels
  • idea of layers like an onion around core functionality of web component
    • annotations as different layers of a source
  • think about wording: (technical) annotations does not mean the same like semantically annotations by researchers
  • styling web components https://css-tricks.com/styling-a-web-component/ 
  • AGREEMENT: we will have web components as a concept
    • advantage: more independent, even if we stick to Ext JS

image-viewer

  • we coded a first draft from scratch: html and js
  • integrated openseadragon

videoplayer (DennisF)

  • at the moment three files: css, html, js → general web component logic has everything in one js-file
  • integration of this web components into Edirom is possible

TechStack

  • web components without Ext JS for touch devices and stay with Ext JS for desktop devices with windows structure vs. quit Ext JS at all and use e.g. mirador instead
    • mirador is a grid system (no overlapping windows)
    • staying with Ext JS means very big dependencies (in the past we had no resources to update it regularly)
    • possibly we try to achieve touch options by upgrading Sencha (we should harmonize it with the developers to not duplicate work)
  • AGREEMENT: we stay with Ext JS and update it (update before web components)
    • web components and afterwards Ext JS update better for edirom online reloaded, for the projects the other way around 
  • ACTION: 
    • everyone is solving some errors in the Ext JS 4 to 6 upgrade (we started to do solve some errors reported by the upgrade advisor in a group); version 6 seems to be a major change
    • upgrade to Ext JS 7 after upgrade to 6 was successful
    • we created an issue #375 with an error-list to get the work distributed

“Konkordanznavigator” (concordance/alignment manager)

  • views for datatypes: video, audio, text etc.
  • killer-feature: synchronization of datatypes and different types of media, aka “Konkordanznavigator”, usage of interlinked data and overlay
    • measure-based in the old edirom has to be rethink to be more “item-based”
    • old edirom: only one type is known <zone @measure>
      ACTION: more generic areas are needed (e.g. sketches do not have “forced” measures)
  • ACTION: create a web component for the Konkordanznavigator
  • we have two concordances in the data: concordance of sources and concordance of annotations

Korngold: Konkordanznavigator

  • Korngold has the need of alignment of video and edition (or even more sources) and navigation with Konkordanznavigator
  • Konkordanznavigator at the moment only “measure”, but unit can also be a time beam (Zeitstrahl), ergo time based Konkordanz
  • the concordance controller can call the measure-element in an MEI encoding or the zone of a facsimile (also SVG can be addressed), nothing to call of a video or audio can be handed over to the concordance controller yet
  • ACTION: create a new Konkordanznavigator plus audio and video which is time based → Konrgold-project will create a draft with requirements and we discuss in a future community meeting

Organizational: repos, labels etc.

  • labels are “grown”, there are different existing labeling strategies 
  • strategy to get work done and to get issues tracked could be improved
    • github project
  • milestones
    • milestone as epics (epics for different repos, milestone for one repo) “label” (like a user story, description of a situation)
    • milestones as time
  • TEI: has a “issue manager” to go through list monthly and re-label and bring issues to 
    • assign a person, that takes care of this ticket (do not have to solve it)
  • MEI: each meeting looks through old tickets/PR starting with PR
  • ACTION: have a look at old tickets (side-project) in edirom online reloaded
  • ACTION: have a look at new tickets and take care of it (also in community meetings) regularly
  • AGREEMENT: we will start to clean the labels up a little bit (eg examine the use of current labels), but do not change to a whole new label system → ideally we achieve more consistency while working on it in the real world
Add a custom footer

Community Meetings

Community

Clone this wiki locally