dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 7 December 2010 12:27, Jo Størset <storset@xxxxxxxxx> 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 <larshelge@xxxxxxxxx>:
>>>
>>>
>>> On Sat, Nov 27, 2010 at 6:03 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> 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