We have not had an up-to-date version of RESTWS in the module repo for
quite a while, and there have been a lot of important changes. Darius would
like to get something into the repo, and I agree, but I don't think the current
version is sufficiently complete and correct to just move on. I have four
reasons for this: (1) we don't have all the 1.8 data model in REST; (2) we have
some known anomalies to fix; (3) we haven't had much experience with the
subclass model; and (4) there will be a competition for resources due to the
need for a version that supports the 1.9 data model.
If I understand Darius correctly, he never thought version 1.0 would be a
complete exposure of the data model, but only a sufficient proof of concept to
assure that the interface would not change drastically. But I believe everyone
who has tried to use RESTWS has found a data object they needed which was not
exposed. If a needed object is not exposed, then the user can't really put
RESTWS to the test. I don't really care what the 1.8-compatible and the
1.9-compatible releases are called, I just want a clear path to a fully capable
1.8-compatible version. I don't want issues (1)-(3) to be lost as we pursue
1.9.
It is not clear how we are going to revise RESTWS as the data model
changes. If I understand Darius correctly, the "v1.0" portion of the URL will
indicate that the module supports 1.8, and will be changed to another value
(most likely "v2.0") when the module supports 1.9. There will probably not be
much backporting (maybe additional queries or custom reps or a
resource-specific catalog call) because most of the changes will depend on the
data model (in the case of 1.8-1.9, location attributes, providers, provider
attributes, visits, multiple providers per encounter, concept mapping, complex
concepts). It seems to make sense to make a new 2.0 head and keep a 1.0
branch, but I don't think we've ever worked on both a branch and the head at
the same time. So I think it would be better to get 1.0 to a more complete,
correct state before we start work on 2.0.
Maybe the sprint schedule needs to be revised to have an RESTWS 1.1 (or
whatever) sprint sooner, and tickets that address 1.9 issues should be given a
new future release fix 2.0 (or whatever). Maybe we can have simultaneous 1.1
and 2.0 sprints.
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
