Darius, Roger, and Whoever,
I wanted to clarify the difference between module and API versions.
Based on the conversation, I think (and would like to confirm) the v1
part of the URL (and Java package) will stay the same as the module
advances to 1.1, 1.2... This is helpful to know since I'm working on a
ticket to expose provider objects for v1.1.
The 2.x module versions will add functionality, nested under /rest/v2...
Thanks,
-Spencer
On 5/15/2012 5:57 PM, Darius Jazayeri wrote:
Roger,
To clarify, I do /not/ think we should have branches of the
webservices.rest module for OpenMRS 1.8.x, 1.9.x, 1.10.x, etc. I
assume that we will release webservices.rest v1.0, and this will work
with OpenMRS 1.8.2+. However if you're using OpenMRS 1.9 with
webservices.rest v1.0 you will not have access to anything that wasn't
available in OpenMRS 1.8 (e.g. Visits, Location Attributes) I think we
should do a "webservices.rest-19ext" module that adds support for all
the new 1.9 features.
My initial thought is that adding new fields to existing resources
(e.g. adding attributes to Location) should not increment the version
number of the REST API. (But this is not well-thought out.)
Regarding whether to release 1.0 or not. I feel very strongly that we
should release 1.0 ASAP, with the current functionality.
Almost a year ago we set out a limited set of functional requirements:
we wanted to satisfy a few key user stories that were suggested by
interested people. (See this wiki page
<https://wiki.openmrs.org/x/94IHAQ>.) We added to that the strategic
requirement that whatever we release as "1.0" should be an API that we
want to support going forwards.
As a result of that requirement we delayed doing a 1.0 release to make
some fundamental design changes. (The bulk of these were spurred by
you, Roger, because you insisted we deal with the issue of subclasses.
I think you were absolutely right to do that, and I think it led to us
doing some very-necessary refactoring of the code. So, a non-sarcastic
"Thanks" for that.)
At this point I really think we need release our current code (just
missing a couple of reviews) as 1.0, and commit to supporting it. Work
can and should continue to happen on the module. It is straightforward
to add some missing resources and release 1.1, 1.2, etc. (For the
record those would be /module/ versions, /not/ API versions.)
-Darius
PS- Regarding competition of resources between finishing off the 1.8
API and doing the 1.9 API...I'd say "patches are welcome". Whatever
tickets people create and vote on, and whatever tickets people claim
and submit patches to, is what will get released first. :-)
On Tue, May 15, 2012 at 3:21 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR)
<r...@cdc.gov <mailto:r...@cdc.gov>> wrote:
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.
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
