> Anyway was just an idea and the people that will work on the backend > will have to decide. But for the demonstrator I could imagine a > quick-and-dirty persistence solution basically based on a single table > with a couple of columns for searching and a XML column for the > composition data like Tom depicted in > http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487 as > "basic serialisation". For this simple approach good XML features are > very important.
Exactly, these are backend questions, not important when building an API. There are many possible solutions, we can discuss them, but people hesitate doing that. It is OK. But what we, as community, can do is building an API to which the kernel can connect, every or most possible persistence solutions should be able to fit below. That is where I would like to help, that is the missing part in OpenEhr which we can do together, so why don't we? Why do discussions die, when they enter this subject? I would like to know that. People discuss very seriuous all kind of subjects, very deeply, that is OK, but why do they never discuss a solution to a Persistence-layer-API? (not the layer itself, only the API.) Another thing that is never discussed, that is the service-layer-API, same question, not the service-laer itself is needed to discuss, only the API. Why is that? I never found an answer to these questions, so I can only guess. Or maybe I missed them, I do not read all emails. Possible. Please tell me, don't stay quiet, but tell me what is happening, not only me, but I think many silent people would want to know. Bert > > Cheers, Thilo > > On Jan 3, 2008 5:35 AM, Hugh Leslie <hugh.leslie at oceaninformatics.com> > wrote: >> Hi Thilo >> >> I would think that Postgres or MySQL or even Firebird would be more open >> source friendly for such a project - nothing against DB2 but with the open >> source engines have no limitations at all and are easy to run on any >> platform... Lots of source code and examples and books etc... >> >> regards Hugh >> >> >> >> Thilo Schuler wrote: >> True, API persistence layer should be generic as said previously >> mentioned. Although originally it needs to be developed based on a >> reference DBMS and for this DB2 looks attractive (quick results?) on >> first sight. >> >> On Jan 2, 2008 8:58 PM, Bert Verhees <bert.verhees at rosa.nl> wrote: >> >> >> Bert Verhees schreef: >> >> >> Thilo Schuler schreef: >> >> >> For openEHR I will concentrate on the GUI part. Had to investigate it >> for a uni project. >> >> Just wanted to let everybody know about IBM DB2 9.5, which I think is >> a fair, "uncrippled" offer. >> >> oh >> >> Sorry, Clicked accidently on Send >> >> I hope someone will pick up this subject, I would be glad to help >> >> So, if someone considers, DB2, or any other DB, that shoudln't matter, >> there are many free DB-engines, it should not be visible in the API. >> >> Bert >> >> >> >> >> >> On Jan 2, 2008 5:18 PM, Bert Verhees <bert.verhees at rosa.nl> wrote: >> >> >> Thilo Schuler schreef: >> >> >> Hi everybody, >> >> just a short note: >> >> I am more a front-end person (plan to start a OSS GUI project in >> 2008), although I have an vested interested in a open persistence >> solution, since I would like to see an end-to-end system demonstrator >> based on OSS components (GUI, kernel, persistence). IMO (and in Rong's >> etc) this would really boost openEHR. >> >> I believe a generic persistence layer API(s) - as Tom said - is the >> way to go. This won't happen in one go. So in a truely agile >> development style this has to happen over several iterations, while >> every iteration product has to be usable! >> >> The reason for this post is that I recently investigated the IBM DB2 9 >> DBMS . This could be a good starting point or reference to build the >> API layer on. >> >> >> If you need any help? >> >> Bert >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> >> >> >> -- >> >> ________________________________________________ >> Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI >> Clinical Director >> Ocean Informatics Pty Ltd >> M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: >> www.oceaninformatics.com >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
