On 7 December 2010 12:27, Jo Størset <stor...@gmail.com> wrote: > Hi, > > seeing if we can keep this thread alive.. > > Den 29. nov. 2010 kl. 04.11 skrev Bob Jolliffe: > >> 2010/11/28 Lars Helge Øverland <larshe...@gmail.com>: >>> >>> >>> On Sat, Nov 27, 2010 at 6:03 PM, Bob Jolliffe <bobjolli...@gmail.com> wrote: >>>> >>>> (i) authentication - currently cookies/html form based which is >>>> awkward. Watching what Jo is doing with basic auth with interest. >>>> The basic auth approach is probably going to be the simplest workable >>>> solution here and we will leverage on what the mobile folk are doing >>>> here. > > I don't think authentication in itself is any issue for this, it is more a > general issue (And a big issue, at that :). > The way dhis security is of today, there is no reason not to just use basic.. > >>>> (ii) management of identifiers/metadata. You can't have reliable >>>> off-site 3rd party client software producing datavaluesets without a >>>> robust exchange of metadata identifiers and codelists. My feeling on >>>> this, which has grown over the past year and a half, is in fact to >>>> stabilize the integer identifiers within a country context. So within >>>> a domain of say Kenya or Tanzania or Sierra Leone, the dataelement >>>> "New malaria cases" should have a fixed identitier (say 42, the >>>> meaning of life). I think the main implication of this is might be >>>> either to do away completely with auto generated ids as primary key or >>>> to also persist an authoritative id - you shouldn't be able to create >>>> a new identifiable object (dataelement, indicator, category or what >>>> have you) without *assigning* it an id. And to do that you must >>>> assume some sort of authority over that metadata element - ie >>>> ownership. In an environment where you might want to create >>>> dataelements from lower down the hierarchy then you either also have >>>> to have an "authority" identifier, or we need to partition the range - >>>> eg 0-1000 are WHO SDMX-HD identifiers, 1000-2000 are national >>>> identifiers and identifiers 10000 and higher are locally assigned. >>>> There are a few ways this could work but we need to solve it and >>>> stabilize somehow. > > If I understand you correctly, I agree with your technical points, we should > assign an id to the entities (and an "authority" should be part of the global > id?). > > But we have to be careful that we don't end up just working where such > assignment is done "right" and changes to the entities are more or less not > allowed (or very controlled). To handle that, there is one thing I think are > missing from the list, versioning. I don't immediately see anything in 2.0.7 > indicating that we are thinking about versioning (maybe you are hoping to > solve it by just requiring "stable" metadata?), so I thought I'd bring it up. > > (iv) Versioning of metadata
To me versioning is not different to stable. ie if a metadata item has an id of 42, an owner of "Kenya National MOH" and a version of 2.4, then I (ideally) expect that id to be constant in perpetuity for that version. > > Any kind of client that can be offline (be it semi-online web client or any > other system) will mean that changes might happen that needs to be captured > in some kind of consistent way in dhis, and that version conflicts needs to > have some way to be resolved. To be able to communicate changes externally > and deal with the differences between the distributed models when > communicating, I think we more or less have three ways to look: > > 1. Build versioning into the core domain > 2. Build a separate api/model for import-export/whatever we call it that > handles versioning in some fashion (but don't really know what that would > look like) > 3. "Declarative" versioning/manual version conflict resolution for api's > talking to external systems (sort of like the current sms handling, and > adding some way to declare changes). > > Versioning potentially adds a lot of complexity, so I am a bit vary of > bringing it up. But I don't think handling versioning individually for each > external api is the way to go and I am pretty certain that trying to pipe > everything through a high level impexp mechanism is not going to work, > either, as more external interactions get more granular. I'm not sure if > light client interaction (think handling many concurrent small interactions) > and big impexp kind of stuff can easily share solutions, but we need to think > through some of the the possibilities. > > Jo _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
