dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

Relevant to the discussion of data exchange:

"A data mesh allows information to be synchronized in a peer-to-peer way,
allowing offline work, and synchronizing with whoever is available, not just
a central database or a service on the internet. This makes it a perfect fit
for situation where there is little/no connectivity or where the
synchronization has to happen between different applications and services."


http://code.google.com/p/mesh4x/

2009/4/23 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> 2009/4/23 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
> > Since this discussion moved from roadmap to import-export and then
> > interchange formats... lemme add something to chew for on import-export.
> >
> > Why aren't we using a diff-based import-export?? Suppose I already have
> an
> > exported file and the new export file only should contain the new values,
> we
> > can generate only the changed values in the export process. Definitely
> > reduces time/ file size for places where import-export will be used
> > monthly/weekly.
>
> Thinking out loud:  the problem with a diff is that you need to have
> something to diff against.  So the program would have to be able to
> read the exported file you already have in order to un-select these
> values from the set in order to export.  On the other hand it would be
> quite trivial (and maybe in the end quicker) to have a dxf-diff
> process which can generate the difference between two exported files.
> Still its an interesting thought ...
>
> > Has anyone thought of object serialization?? Where we could serialize
> > objects and move it to new places... A radical and stupid way, but may be
> > useful for GIS import-export, where the dxf format may fall short on
> > representing sharable geographic information. Disease surveillance on the
> > CBHS may be one candidate...
>
> Can of worms here - the respective merits of native serializing
> (presumably) vs serializing to XML.  Personally I would always go for
> the latter.
>
> I am not up to speed on exactly what shareable geographic information
> we might want to share, but it makes sense to use an open geographical
> markup language to do it (like GML) rather than trying to reinvent the
> wheel in dxf.  Spurious example:
>
> <dxf xmlns:dx="www.hisp.info/dxf" xmlns:gml="
> http://www.opengis.net/gml/3.2 >
>
> <dx:DataValue DateElement=... Value="32" >
>   <dx:Location>
>      <gml:Point>
>       <gml:coordinates>100,200</gml:coordinates>
>    </gml:Point>
>   </dx:Location>
> </dx:DataValue>
>
> Thats not a good example.  Real life might be more interesting ... but
> there is no good reason why we couldn't quite easily get geographic
> information into dxf.  The beauty of namespaces.
>
> Cheers
> Bob
>
> >
> > ---
> > Regards,
> > Saptarshi PURKAYASTHA
> > Director R & D, HISP India
> > Health Information Systems Programme
> >
> > My Tech Blog:  http://sunnytalkstech.blogspot.com
> > You Live by CHOICE, Not by CHANCE
> >
> >
> > 2009/4/24 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> >>
> >> 2009/4/23 Lars Helge Øverland <larshelge@xxxxxxxxx>:
> >> >
> >> >>
> >> >> 6 complicates the current import strategy where objects get imported
> >> >> "on
> >> >> the fly" without temporary storage, maybe we can put this on hold.
> >> >
> >> > Actually this holds for 5 as well...
> >> >
> >>
> >> I'll have to look at this more closely - though I know you will have a
> >> better idea of what is going on.  In principle it shouldn't really
> >> matter.  All that's happening in 5 is that we import a <Period> object
> >> (on the fly, in its entirety or what have you).  Then we just use the
> >> inherited periodID attribute as we import all the contained
> >> dataValues.  I am not seeing how this would be fundamentally
> >> different.  Could be I'm just tired and in need of a beer ...
> >>
> >> Cheers
> >> Bob
> >
> >
>



-- 
Cheers,
Knut Staring