On further review, it seems to me that while there are certain types of changes 
to the data model that can be made without breaking RESTWS, others cannot.  For 
example, adding a new nullable field to a table requires a change to the 
creatable and updatable field lists and to the could-be-missing field list 
within the resource (as well as corresponding changes in the .hbm and pojo), 
but existing calls to the resource will still work correctly, so it doesn't 
break anything.  But adding providers and using them as a mapped collection in 
encounters instead of a user reference does break things, you can no longer 
create an encounter with a user.

I am beginning to think that we should roll RESTWS into core so that it moves 
with its version-appropriate data model.  So 1.9.1 should include a RESTWS 
appropriate to its data model.  That would leave the "v1.0" portion of the URL 
to handle changes in the semantics of the calls, should that ever happen.  And 
1.8 would be the only version to use the RESTWS module (or we could roll it 
into 1.8.4 or whatever is next).

From: dev@openmrs.org [mailto:dev@openmrs.org] On Behalf Of Darius Jazayeri
Sent: Tuesday, May 15, 2012 7:57 PM
To: openmrs-deve...@listserv.iupui.edu
Subject: Re: [OPENMRS-DEV] RESTWS release timing/content

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]

Reply via email to