Correct.  We definitely do not want to be changing the REST URLs with each
minor update of the module.

-Burke

On Tue, May 15, 2012 at 10:13 PM, Spencer Kathol <spen...@kathol.net> wrote:

>  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> 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<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from 
>> OpenMRS Developers' mailing list
>
>
>   ------------------------------
> Click here to 
> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from 
> OpenMRS Developers' mailing list
>
>  ------------------------------
> Click here to 
> unsubscribe<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