Notes from 28-Feb-2017 Meeting; Next call 14 March 14:00 UTC

28 Feb 2017

It was a small group today, just myself, Frederik and Ulrich.
We discussed Thomas' Reptor implementation. Frederik suggests that maybe
one approach to addressing the complexity issue would be to make it
required for server implementations to explicitly declare the default
values for the required elements of the schema. Since the default values
should represent the lowest common denominator behavior, it should mean
minimal burden on the server implementation and enable clients to have a
consistent interface to write to. Bridget volunteered to fork the Reptor
implementation in to the group GitHub repo and try to add this to it to
verify that it can be done with minimal effort.
We agreed that we want to keep the specification of success and error
responses minimal, but that addition of a very basic structure like
those used for the error code (e.g. an object which provides fields for
a code and a string)would be useful for success responses. Bridget will
add this to the spec.
The sample implementations should also each have an API route which
provides the swagger spec so that we can point the swagger UI at them to
demonstrate the calls. Bridget will add this to the forked Reptor
implementation and Frederik will add to his. (I think Alex's already has it)
Frederik reported on the joint effort between him and Alex to develop a
shared python library that can be used with different database backends.
They are using the model classes as parameter types (rather than
serializations of the models).
We also discussed a request from Kathy (our secretariat liaison) to do a
recommendations presentation at P9. Frederik and I felt it was too soon
and would like to decline. Bridget will draft a mail to send to Kathy
in response.

  • Thomas Zastrow's picture

    Author: Thomas Zastrow

    Date: 28 Feb, 2017

    Dear all,
    Please don't fork the Reptor software into another repository. The
    collection API implementation is just a small part of the Reptor
    application and I'm absolutely willingly to hand over this part of code
    to someone else.
    But forking the project would mean to divide forces and make it
    difficult for further developers and users to decide which fork to
    follow. In fact, I know that the software is not really stabil currently
    and I want to spent some more time on stabilizing it before the next
    plenary. A fork would not benefit from these enhancements (or it would
    be even more difficult to include them and at a certain point both forks
    will be no longer compatible).
    So lets join forces and not split them up.
    Best,
    Tom

  • Tobias Weigel's picture

    Author: Tobias Weigel

    Date: 28 Feb, 2017

    I think the intention was not to sustain the forked branch, but to do
    the forking with the goal in mind to make the improvements and later
    pull the changes back into the main Reptor repository. At least this
    would be the standard git way of doing this. Or are there other things
    relevant that I am currently overlooking?
    Best, Tobias

  • Thomas Zastrow's picture

    Author: Thomas Zastrow

    Date: 28 Feb, 2017

    OK, if this was the intention its fine of course. (I interpreted the
    fork into the groups GitHub repository different).

  • Bridget Almas's picture

    Author: Bridget Almas

    Date: 28 Feb, 2017

    Exactly that would be the point -- to do the work in a fork and then
    send a pull request to get them back into the main branch.
    Although we also said that we wanted all the implementations presented
    by the group to be available in group's github organization, which is
    another motivation for forking right now.
    Tom I think my main concern is that we, as a group, present
    implementations that all implement the same API. I think this is
    critical to the success of the WG output.
    Best
    Bridget

submit a comment