Ben,
Yes, it was not discussed since you were missing and we wanted you to be
part of the decision... also time was short and it seemed like a decision
on the list could be reached.

Yes, I can confirm that it doesn't work, if we've built the module using
1.9.0-RC3 and then say require version to be 1.8.1 and have the
LocationAttributeResource that uses the LocationAttribute class. Spring
doesn't like it and throws the following exception:
http://pastebin.com/GBy9bRyW

I think resource versioning is fairly trivial. If the resource changes in
its representation (or params it takes), we should make it v2 (or v1.1) and
then only that resource has a v2 in its URL while others have v1. This is
how many services exist where resources have different versions in the same
release.

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE


On 17 May 2012 03:35, Ben Wolfe <b...@openmrs.org> wrote:

> I don't see this in the notes for the design call today, so I assume it
> wasn't discussed.
> http://notes.openmrs.org/Design-Forum-2012-05-16
>
> I do NOT want branches for the module.  I also would prefer to not have
> the -ext modules.  Can someone confirm that the rest module def does not
> start up if the provider classes are just on the path?  If it fails, I
> assume it is because of classpath scanning by us or by spring.  The former
> could be caught and handled gracefully.
>
> Adding a v2 of a resource would come at any point, I think.  I don't the
> the v1/v2/v3 versions match the rest module version which doesn't match the
> openmrs version.  (We will need to document each rest method and keep it
> updated on the wiki to make alleviate developer version matchings)
>
> Ben
>
>
> On Wed, May 16, 2012 at 5:59 PM, Darius Jazayeri 
> <djazayeri+...@gmail.com>wrote:
>
>> Yes, my suggestion is that we'll have to manage up to a couple of -ext
>> modules, for supported versions of OpenMRS. At some (way future) point we
>> might decide to stop supporting 1.8 in active web service development, and
>> we could fold -19ext into the main webservice module, and increase the
>> required version to 1.9.
>>
>> I think Ben prefers to branch the module instead (so we'd have a
>> 1.8-compatible branch, a 1.9-compatible branch, etc).
>>
>> Let's discuss this (in a time-boxed way!) on the design call today, as
>> neither Ben or I are experts on this.
>>
>> Another question: what happens when we introduce an incompatible
>> variation of a resource (e.g. in 1.9 concept.mappings changes
>> significantly)? Would we make that v2 of the concept resource only? Or does
>> introducing v2 imply incrementing the version of the whole API? (And thus
>> we might try to hide the new concept map structure under the hood.)
>>
>> -Darius
>>
>>
>> On Wed, May 16, 2012 at 7:41 AM, Saptarshi Purkayastha 
>> <sun...@gmail.com>wrote:
>>
>>> So is the plan that with every new data model change in the core, there
>>> will another web service extension module??
>>> That means to get web services in 1.10, I'd have to install the
>>> webservices.rest, the webservices.rest-19ext and then
>>> webservices.rest-110ext (or the new webservices-110.ozip)
>>>
>>> So, Spencer Kathol's work on the Provider should be in the
>>> webservices.rest-19ext module and not in 1.1
>>>
>>> ---
>>> Regards,
>>> Saptarshi PURKAYASTHA
>>>
>>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>> You Live by CHOICE, Not by CHANCE
>>>
>>>
>>> On 16 May 2012 19:55, Darius Jazayeri <djazayeri+...@gmail.com> wrote:
>>>
>>>> Saptarshi,
>>>>
>>>> I think that for the foreseeable future, all versions of the restws
>>>> module (1.0, 1.1, 1.2, etc) will require OpenMRS 1.8.1.
>>>>
>>>> So, webservices.rest 1.1 will still require OpenMRS 1.8.1. In addition
>>>> we'll have a webservices.rest-19ext that requires 1.9 and provides the
>>>> additional 1.9 resources.
>>>>
>>>> Roger,
>>>>
>>>> I actually think there's a benefit to having our REST API change more
>>>> slowly than our java API. (It would be wonderful to be able to build a
>>>> future version of sync based on having 1.8, 1.9, and 1.10 children all
>>>> synching over web services.)
>>>>
>>>> -Darius
>>>>
>>>>
>>>>
>>>> On Wed, May 16, 2012 at 4:58 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <
>>>> r...@cdc.gov> wrote:
>>>>
>>>>>  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> 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
>>>>>
>>>>
>>>>
>>> ------------------------------
>>> 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