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

You are here

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.

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

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

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