dhis2-devs team mailing list archive

[samuel cheburet <samuelcheburet@xxxxxxxxx>]

Thanks for sharing the information on what other developers have done. I
believe we can make a good implementation matrix on what is required to be
added/fix in dhis 2.0.6.

I wish all of you nice week.

Regards

On Tue, Nov 23, 2010 at 5:14 PM, Knut Staring <knutst@xxxxxxxxx> wrote:

> When we revive this discussion for 2.0.7, we may want to take a look
> at what the Worldbank has done on data.worldbank.org.
>
> Particularly for exposing their data and even offering a competition
> to use their REST API to develop apps on top, including mobile ones:
>
> http://data.worldbank.org/developers
>
> Perhaps someone you know would even like to make 15k USD creating a cool WB
> app:
> http://appsfordevelopment.challengepost.com/
>
> If we adopt parts of their API, we may even be able to point people to
> the WB apps for dissemination and visualization.
>
> Knut
>
> On Wed, Nov 10, 2010 at 12:13 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> wrote:
> > Hi
> >
> > On 9 November 2010 05:58, Jo Størset <storset@xxxxxxxxx> wrote:
> >>
> >> Den 8. nov. 2010 kl. 23.43 skrev Lars Helge Øverland:
> >>>
> >>>
> >>> Required note: As long as we don't call it REST :) REST imples a
> >>> hypermedia-driven application, so let's stick to calling it what it
> would
> >>> probably be: a simple web api.
> >>>
> >>
> >> Hey be a bit more visionary:) I think this is a great thought.
> >>
> >> Ok, if you say so :)
> >>
> >> We are getting more and more requests from people who want to use their
> own
> >> presentation layer (Ifakara folks in Tanzania will "make a web-based
> query
> >> tool on top of dhis2", Uganda folks are integrating dhis2 with a CMS
> etc).
> >> I'm envisioning methods for:
> >> - getting all data elements/indicators with (a bit extended) DXF and
> HTML
> >> format responses with embedded links to URLs pointing to a method giving
> you
> >> the full details for each as HTML or PDF.
> >> - getting all indicators with DXF/HTML responses with links to URLs
> pointing
> >> to a PNG chart giving the aggregated vales for the 12 last months.
> >> - getting all report tables as DXF/HTML with links to URLs pointing to
> >> SDMX-HD/HTML/PDF/Excel representations of the table.
> >> - getting all orgunits for a given parent as DXF/HTML with links to URLs
> >> pointing to GIS PNG images, and so on...
> >> There you have your hypermedia-driven application that moves from one
> state
> >> to the next by examining and choosing from among the alternative state
> >> transitions in the current set of representations.
> >> This kind of stuff will give potential users an elegant way of
> integrating
> >> dhis2 data into whatever tool they prefer and avoid hacking into the
> >> database or fumbling with the source code. If don't want your users to
> >> leave, make it easy for them to do so:)
> >>
> >> I had hoped that the mobile case could serve as a starting point for
> >> exploration in this area, but basically the mobile use case makes more
> sense
> >> as a "custom protocol" as it is now, so it has ended up as little more
> than
> >> an introduction of jersey (which I still think is the right kind of tool
> for
> >> this). So, at a practical level, I think we should start by identifying
> a
> >> specific use case where we can explore how such an api might make sense,
> >> without too much custom requirements for how it should be built.
> >> Distilling your list above might be a good start to get a sense of how
> to
> >> model an "application level" model (but we should probably have some use
> >> cases for making changes through the api, as well). I would certainly be
> >> interested in working on this, but I do have other commitments and don't
> >> really know the domain well enough to get the modeling right by myself.
> You
> >> would of course have to get Bob onboard (I'm not sure what he's wasting
> his
> >> time on these days, but I'm guessing it has to do with excel :), and
> >> probably be prepared for some changes to the way we map metadata to xml
> :)
> >> One problem with the hypermedia part is that there isn't really much
> mature
> >> tools that easily support this kind of api building. With jax-rs we
> >> have basically gotten a better alternative to servlets, but still the
> way to
> >> build decent linkable representations and mapping to standardized
> content
> >> types haven't really settled down into solid best practices. And with
> the
> >> amount of time it has taken for the rest community to come up with this
> kind
> >> of tool support, I'm not really sure it will materialize anytime soon.
> There
> >> are people building more innovative solutions out there, but those tools
> >> then are more bleeding edge or move into too different technologies from
> our
> >> current stack.
> >> There are also some difficult "ground rules" we have to make the right
> trade
> >> off for, if we want to give this a go. We have to make a rough cut as to
> >> what makes sense to target for such a web interface versus more
> >> batch-oriented import/export and low-level interfaces for
> performance. We
> >> have to make a decent 80/20 trade off for what would be the important
> use
> >> cases to model support for in this way. And we need to have a sense of
> how
> >> much weight we want to put into supporting old-school soap stuff (I know
> Ime
> >> has a little requirement for some support there, but not sure how many
> >> others are still subscribing to that way of modeling apis).
> >> Basically, I think it is a difficult challenge to both support larger
> >> import/export structures (where size is a main concern) and more fine
> >> grained representations (where it is more about finding the right
> >> granularity representations and integrating links in a natural way). I'm
> not
> >> sure how easy it is to model these two use cases with the same set of
> >> document structures.
> >
> > I think it's definitely possible (and highly desirable) to use the
> > same xml bindings for dhis entities for all use cases within dhis.
> > Larger structures are just compositions of the finer grained ones,
> > Having 3 different xml renditions of a dataelement structure in a
> > single application is not efficient.  So I would certainly like to see
> > a common set of jaxb bindings to an xml which we can all agree is
> > useful and which can be used for mobile, import/export and ajax
> > exchange (the 3 case I see now).
> >
> > There is certainly a case for having stream based input through a
> > common import point as well as finer grained services.  What is
> > preventing this being done comfortably at this point is the fact that
> > we haven't yet resolved the problem of identifiers satisfactorily.  So
> > going outside the stream based import we are obliged to either put our
> > heads in the side regarding database ids or we have to take steps to
> > ensure that we have a very, very closed system.  Of course if we are
> > talking about the purity or otherwise of REST(ish) approaches this
> > question of URIs is absolutely fundamental.  Moreso than some of the
> > other concerns raised about how restful is restful.  Solving the
> > problem of interacting with 3rd party systems (finegrained, restful or
> > otherwise) still fundaentally comes down to solving the problem of
> > identification.
> >
> > My own sense after having looked at the range of
> > uniqueness-based-on-name, vs database integer id, vs urn vs uuid ...
> > is that we probably need to resign ourself to the fact that integer
> > ids are just plain useful and efficient so we need to address two
> > problems of
> > (i)   stabilizing them (save explicitly, rasther than depend on auto
> sequences)
> > (ii)  quailfy them to give them global uniqueness outside of internal
> > scope ;  eg what is known to the world as
> > http://dhi2.org/ke/dataelement/id/4 is known internally as 4.
> > Composition of URI is just example.  Lots of politics around how this
> > uri is formed.  In fact I can even see a possible real world use for
> > the WHO indicator metadata repository here.
> >
> > There are a couple of pressing needs for non-browser based interaction
> > with dhis.  One being the downloading of updates to aggregatedatavalue
> > tables for offline pivot table cache refresh.  Though rather than
> > place a requirement for web api to be functional first, I intend to
> > proceed with libcurl for now.
> >
> > Regards
> > Bob
> >
> >> Jo
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~dhis2-devs
> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~dhis2-devs
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dhis2-devs
> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dhis2-devs
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
>
> --
> Cheers,
> Knut Staring
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Samuel Cheburet
Ministry Of Health
P.O. Box 20781
Nairobi, Kenya
Mobile- 0721624338