Thomas Beale schreef: > Bert Verhees wrote: > >> 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. >> >> >> > *I would think the problem here is that no-one knows at this stage what > you are asking them to consider. Is it: > - just an idea (i.e. why don't we write a new persistence layer together) > - an implementation that you have running or partly running, but you > need more effort on it > > Probably you need to clarify the concrete basis of this discussion from > your point of view. > The fact is, I have a persistence layer running, can be optimized on some places (working on that), but is does it job. I don't need others to help me.
(please forgive me for repeating myself, but maybe I did not say it clear) It is not that I want people to write together a persistence layer, I am thinking about an API to a persistence layer, an abstraction layer to which the kernel and the persistence layer can fit to. One could then write an example persistence layer to fit on to that, but that would not be the point. I think there are some problems with the Java-kernel and getting it fitted into an API (on the top-side), because of some reasons, and I hope, that when a persistence API layer is build, these problems will show up, and will reflect on further Java-kernel development. Because, the java-kernel from Rong is a good piece of work, very usable as a code-base, but it is handicapped, and it stays that way, because it is not noticed because it is not used (as far as I know). For me, I have to rewrite all the time, because, as the kernel is know, I have to work on a fork. The most important problems are its immutability forced in code, not having setters (at least protected, everywhere) and, there are some algorithms in some setters, which can be avoided, and also, can throw exceptions. This is wrong I think, because you don't want exceptions at places a persistence layer uses to fill up objects, this is against ACID (you have a nice transaction below, and without knowing, a part of the transaction is disturbed on a higher level, and in code, you need to roll back that parts of the database-transaction which did fine.). There are also problems with the fact that Java cannot do multiple inheritance, which leads to redundant code. So all together quite some things eed to be solved when building a persistence layer. There may be some discussion on some points, I can be wrong. Possible. We had these discussions a year ago, but suddenly we were discussing AspectJ and other things by people who had not to deal with consequences of what they were suggesting. Anyway, none of the problems I mentioned then, came close to a solution, a very frustrating experience. That is why I now came to the conclusion, that writing a persistence layer would help solving these problems. Not for me, I solved them, but it is a waste of time having to work on forked code. And what is more, if there is an open source implementation, meant to be a product, then more people will help solve problems, I think this will lead to an elegant product. About this is why I do all this trouble. Maybe, a motivation can also be on open source base, others can help me find other reasons why a persistence layer-API would be a good idea. Please note the word *API*, a lot of people confuse it with the persistence layer itself. bert > - thomas > * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
