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 <knu...@gmail.com> 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 <bobjolli...@gmail.com> > wrote: > > Hi > > > > On 9 November 2010 05:58, Jo Størset <stor...@gmail.com> 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@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~dhis2-devs > >> More help : https://help.launchpad.net/ListHelp > >> > >> > > > > _______________________________________________ > > 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 > > > > > > -- > Cheers, > Knut Staring > > _______________________________________________ > 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 > -- Samuel Cheburet Ministry Of Health P.O. Box 20781 Nairobi, Kenya Mobile- 0721624338
_______________________________________________ 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
