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 <[email protected]> > 2009/4/23 Saptarshi Purkayastha <[email protected]>: > > 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 <[email protected]> > >> > >> 2009/4/23 Lars Helge Øverland <[email protected]>: > >> > > >> >> > >> >> 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
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
