Thanks, Heath, you sure give some interesting things to look after. I will (but not today)
Bert Heath Frankel schreef: > Bert, > I think there might be a few reasons why a discussion on persistence might > come to a halt: > * lack of time > * lack of interest > * lack of knowledge on the topic > > I certainly don't think anyone is deliberately trying to stop this > discussion and I agree that discussion would be beneficial to the community. > Sure there might be some commercial interest on the topic but that does not > stop others having the discussion. However, the topic of a persistence API > I don't see as much of a commercial issue as a persistence model. In fact > the persistence model becomes more irrelevant when a common persistence API > is available. Tom has already indicated that Ocean intends to publish its > APIs, which takes resources, so the task gets assigned a priority alongside > many other high-priority tasks. > > In addition, I think there is some misinterpretation about the terms being > used in this discussion such as persistence API. The original email from > this thread talked about a particular implementation of a persistence API > using a particular DBMS. Tom, then talked about publishing an API > specification and Bert, you are advocating discussion about an persistence > API which I interpreted as being the specification of an API but perhaps it > was more a OS Java implementation so that it can be used with the OS Java > Kernel so that you can replace it with your own by changing the facade of > your persistence API to comply with the OS API. > > Well, if you want that discussion about implementing a Java Persistence API > then I will not stop you, but I will not participate as I have no interest. > This is why a discussion on an API specification would be more appropriate > for the wider community and leave the discussions about a specific Java > implementation to a smaller group of people that are interested and base > that implementation on the API specification. > > Having said all that, I do have a comment about the OS Java Kernel binding > to a persistence API. If we a look at the openEHR Architecture Overview, > there is an Architecture diagram (Figure 37) that suggests that the openEHR > Kernel (within the Virtual EHR built into a clinical application) does not > directly bind to a persistence API, but uses an EHR Service (I use the term > 'Service' in it most generic sense, it does not need to be a Web Service). > Therefore, I suggest we should be working on this EHR Service API > specification and a reference implementation that might use some specific > persistence implementation. If there is enough interest to define the > Persistence API also then that could be done also, but that would not > directly affect the OS Java Kernel. > > BTW, leading up to MedInfo '07 Rong implemented an EHR Service binding to > the Ocean EhrBank Web Service within the OS Java Kernel. I am not sure if > this was committed to the svn repository but if it has been then you will be > able to see the Ocean EhrBank Service API. This API has been refined > slightly since MedInfo but it will give you some idea of what it looks like. > It is quite a simple course-grained API and relies heavily on AQL (formerly > known as EQL) and openEHR RM (as you would expect) to provide its > capability. > > > Regards > > Heath > > Heath Frankel > Product Development Manager > Ocean Informatics > > >> -----Original Message----- >> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >> bounces at openehr.org] On Behalf Of Bert Verhees >> Sent: Saturday, 5 January 2008 1:00 AM >> To: For openEHR technical discussions >> Subject: Re: persistence >> >> Karsten Hilbert schreef: >> >>> On Fri, Jan 04, 2008 at 02:31:57PM +0100, Bert Verhees wrote: >>> >>> >>> >>>> Exactly that is what I am doing, and to not reinvent wheels >>>> unnecessarily, >>>> >>>> >>> Good ! >>> >>> >>> >>>> I am calling others to help do it. >>>> >>>> >>> Makes sense. >>> >>> >>> >>>> Because, I am already figuring out how to do it, others can share and >>>> use my experience, >>>> >>>> >>> No they (currently) cannot (easily in an OSS way) because >>> ... >>> >>> >>> >>>> But I am not going to do the first step, because, there is no one who >>>> > is > >>>> wanting to help, and an Open Source project from one person is small, >>>> > it > >>>> can stay in my house. Then publishing is of no use to me. >>>> >>>> >>> ... they do not have access to your experience (in code). >>> >>> Note that I am NOT saying you *have* to share the code. >>> >>> >> What I need is a strongly expressed intention to do something in a way I >> suggest. >> Serious people, not , say, pbublish your thing, and we will see. That is >> not good enough. >> >> If we have a few people which want to join, and they seriously have >> thought about in what way to join, then we discussi further how to >> > proceed. > >> And I am not suggesting that I have found the holy grail, or that I am >> looking for it, it is, like you said before, there is a job to do. >> >> 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 > > > >
