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
