16_Oct_Mtg_Notes < IVOA

IVOA Web>IvoaTCG>DALGWSTigerTeam>16_Oct_Mtg_Notes (2024-10-21, MarkusDemleitner) (raw view)
---+ P3T meeting with Clients - Oct 16, 2024

---++ Attendees
   * Attendees:
      * Pat D, Gregory DF, Adrian D, Brian Major, Brian McLean, Dave M, Frossie E, Grgory M, Jesus S, Jose O, Joshua F, Marco M, Mark A, Markus D, Pierre F, Pierre L, Renaud S, Russ A, Sara B, Tamara C, Janet E
   * _Regrets_ :
---++ <a name="Zoom"></a>Zoom

---++ <a name="Highlights"></a>Highlights
   * Great group attendence at 22
   * P3T team presented Documents and prototype work completed so far
   * Discussion with Apps and P3T was constructive and supportive with some concerns
   * Concerns centered on ...
      * backward compatibility with client code
      * major version changes to standards in the VO in general (somewhat tangential)
      * It was noted that there is code in the VO with different versions of the standards deployed
   * Actions:
      * Janet draft invite to Clients via Apps group after discussing at TCG -- DONE
      * Dave prepare ~2 slide for clients mtg with <a href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/P3T?topicparent=IVOA.23_Sep_Mtg_Notes;nowysiwyg=0" rel="nofollow" title="P3T (this topic does not yet exist; you can create it)">P3T</a> prioriites as a reminder -- DONE
      * JE with <a href="https://wiki.ivoa.net/twiki/bin/edit/IVOA/P3T?topicparent=IVOA.23_Sep_Mtg_Notes;nowysiwyg=0" rel="nofollow" title="P3T (this topic does not yet exist; you can create it)">P3T</a> help: Prepare mtg page for Client mtg early with links to docs and perhaps a prototype(?!) -- DONE
      * ALL: Review the draft docs so we present them to the Clients after internal review
      * ALL: Look at each others prototypes to know we're on the right track here too before Client mtg
---++ <a name="Meeting Agenda/Notes"></a>Meeting Agenda/Notes
   * Overview/Reminder of what we're setting out to do - From Dave
      * <a data-sk="tooltip_parent" data-stringify-link="https://github.com/Zarquan/jordanita/blob/main/presentations/20241016-IVOA-P3T/20241016-IVOA-P3T.pdf" href="https://github.com/Zarquan/jordanita/blob/main/presentations/20241016-IVOA-P3T/20241016-IVOA-P3T.pdf" rel="noopener noreferrer" target="_blank">https://github.com/Zarquan/jordanita/blob/main/presentations/20241016-IVOA-P3T/20241016-IVOA-P3T.pdf</a>
      * Why are we doing this?
      *
         * <span data-mce-mark="1" style="background-color: transparent;">Cost to projects - developer time</span>
         * <span data-mce-mark="1" style="background-color: transparent;">Complexity a barrier to adoption</span>
         * <span data-mce-mark="1" style="background-color: transparent;">Security - some patterns are not meeting modern security recommendations</span>
      * <span style="background-color: transparent;">What's in scope</span>
         * <span style="background-color: transparent;">Machine readable (OpenAPI)</span>
         * <span style="background-color: transparent;">Compatible with current</span>
            * <span style="background-color: transparent;">development frameworks</span>
            * <span style="background-color: transparent;">tools & IDEs</span>
      * <span style="background-color: transparent;">What's out of scope</span>
         * <span style="background-color: transparent;">Solving other problems</span>
         * <span style="background-color: transparent;">Want to isolate this work</span>
   * Pointer to Docs/Prototypes
      * Draft docs: (Russ)
         * Draft IVOA web service standards framework - <a href="https://sqr-091.lsst.io/" target="_blank">https://sqr-091.lsst.io/</a>
         * Draft IVOA [[SODA]] web service specification - <a href="https://sqr-093.lsst.io/" target="_blank">https://sqr-093.lsst.io/</a>
         * Draft IVOA JSON encoding - <font color="#58438b"> https://sqr-092.lsst.io/ </font>
         * <span style="background-color: transparent;">Layered approach to specifications</span>
         * <span style="background-color: transparent;">Docs are just intended to be an example of the layering</span>
      * Prototypes in GitHub
         * UWS Implementation (Josh)
            * OPENAPI Doc: [[https://www.google.com/url?q=https://github.com/ivoa/PTTT/pull/1&source=gmail-imap&ust=1728413194000000&usg=AOvVaw2K_7ldyYOvZ63YIfoeuDMT][https://github.com/ivoa/PTTT/pull/1]].
            * Example implementation: [[https://www.google.com/url?q=https://github.com/spacetelescope/fastapi-uws&source=gmail-imap&ust=1728413194000000&usg=AOvVaw1Roe0HFRc6QugDbUE_V5uC][https://github.com/spacetelescope/fastapi-uws]]
            * *UWS spec direct link:* https://github.com/jwfraustro/PTTT/blob/UWS-MAST/uws/openapi.yml
         * TAP-.2 (1.1 + user table extension) - Pat
            * OpenAPI spec: [[https://www.google.com/url?q=https://github.com/pdowler/PTTT/tree/main/tap&source=gmail-imap&ust=1728407562000000&usg=AOvVaw3-th0f2IEbycEG-r_xR36I][https://github.com/pdowler/PTTT/tree/main/tap]]
            * <span style="background-color: transparent;">Using (referencing) libraries from openapi.yaml (uws, tap, vosi, …)</span>
            * <span style="background-color: transparent;">Tricky part was separating TAP/UWS responsibility</span>
               * <span style="background-color: transparent;">TAP describes the jobInfo</span>
               * <span style="background-color: transparent;">UWS the interactions</span>
            * <span style="background-color: transparent;">Async: Both the UWS and TAP API response codes must be described together</span>
            * <span style="background-color: transparent;">Sync: Even more redundancy/overlap than in async</span>
            * <span style="background-color: transparent;">Lint tools report conformance</span>
            * <span style="background-color: transparent;">Payload modelling not particularly attractive</span>
               * <span style="background-color: transparent;">But referencing specs is easier to do</span>
            * <span style="background-color: transparent;">Pat Question: is this easier to read/understand?</span>
               * <span style="background-color: transparent;">Mark T: yes, easy to read</span>
         * Execution Broker (Dave)
            * OpenAPI component: <a data-sk="tooltip_parent" data-stringify-link="https://github.com/Zarquan/Calycopis-broker/blob/main/openapi/ivoa/openapi-0.8.yaml" href="https://github.com/Zarquan/Calycopis-broker/blob/main/openapi/ivoa/openapi-0.8.yaml" rel="noopener noreferrer" target="_blank">https://github.com/Zarquan/Calycopis-broker/blob/main/openapi/ivoa/openapi-0.8.yaml</a>
            * <span style="background-color: transparent;">Added the execution planning model (payload) to openapi </span>
               * <span style="background-color: transparent;">Inheritance works really well</span>
               * <span style="background-color: transparent;">Able to describe complex string formats and validators</span>
   * Apps/P3T group feedback to Docs/Prototype work - Discussion
      * <span style="background-color: transparent;">Russ: would a standardized encoding format be useful to the standardization process?</span>
      * <span style="background-color: transparent;">Mark T: How about backward compatibility?</span>
         * <span style="background-color: transparent;">(Note: the prototypes shown are not backwards compatible)</span>
         * <span style="background-color: transparent;">Russ: a new start with these tools</span>
         * <span style="background-color: transparent;">Mark T: we should prioritize backward compatibility over tooling support</span>
         * <span style="background-color: transparent;">Markus: experience with SIAP1 & SIAP2. 2 introduced in 2018, but 1 still more prevalent. Fragmentation in major versioning should be avoided. IVOA is a disparate group of implementers with different timelines and budgets.</span>
         * <span style="background-color: transparent;">Josh: can't avoid doing major version changes</span>
         * <span style="background-color: transparent;">Frossie: Would be good to know the understanding of effort to make the proposed backwards compatibility changes.</span>
         * <span style="background-color: transparent;">Pierre F: What are the details of what is not backwards compatible?</span>
            * <span style="background-color: transparent;">Russ: rough answer: error handling at a different layer (http rather than payload), issues around data types, xml translation to other protocols, etc. A collection of smallish, client-service interactions.</span>
            * <span style="background-color: transparent;">Dave: case sensitivity not supported out-of-box, form encoding not recommended because of security issues</span>
         * <span style="background-color: transparent;">Dave on major versioning: should solving this problem be a separate effort?</span>
         * Markus: going this route would require active management to ensure the rollout of the deployment across the VO, in particular reaching out and actively communicating with the data centres with clear communication what they need to do and what it takes to do it.
         * <span style="background-color: transparent;">Gregory D-P: the library implementation ecosystem isn't sufficient to write the suite of VO services.</span>
      * <span style="background-color: transparent;">Pierre L: appreciates the effort being made to having better described standard definitions.</span>
      * <span style="background-color: transparent;">Dave: Are there any other issues we haven't addressed? </span>
      * <span style="background-color: transparent;">Marco: What is the extent of the backwards compatibility changes we should make? There are options.</span>
      * <span style="background-color: transparent;">Pierre F: Would it be valuable to try to prototype a more simple protocol such as SIA? It would be good to have more specific details of what changes are necessary.</span>
      * <span style="background-color: transparent;">Summary</span>
         * <span style="background-color: transparent;">Backwards compatibility with client code the main concern</span>
         * Major version changes to standards in the VO in general (somewhat tangential)
         * It was noted that there is code in the VO with different versions of the standards deployed
   * Looking ahead to the Nov Interop
      * Schedule topic to organize program of session at Next meeting;; We're scheduled 2-3:30 on Friday, Nov 15
      * Marco suggested leaving plenty of time for discussion with audience.
      * JE suggestion for folks to consider ... talks 10-12 min for Proto/Doc talks; 10 min Janet/Brian and keep all question to end?? That leave ~30 min questions/discussion. Could make it a panel and include a few apps ppl???
         * 2 minute intro - Janet
         * Prototypes/Implementations -- What's the angle we want to present?? Do we try to answer a short set of questions??
            * Josh
            * Pat
            * Dave
         * Documents
            * Russ
         * Wrap-up/Discussion - Brian
   * Next meeting:
      * 2 suggestions: Wed, Oct 23 @20UTC or Wed, Nov 06 @20UTC (JE traveling week of Oct 27)

<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Topic revision: r7 - 2024-10-21 - MarkusDemleitner
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema