Hi Bert, Bert Verhees wrote:
> Please correct me if I am wrong, > > Please take it as a request for information, or if I am wrong and need > to be corrected, as a discussion. > > I will do a few statements about what I have seen around the > openehr-website > > - The folder in the RC 1 for ITS is a bit empty. No > database-definitions, no languages specific information, no > distribution-formalism. > As the roadmap-document explains, this will be taken care of, but has > not yet happened. there is a Java ITS guide, which will be included here. The documentitself is available at http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/its/Java/openEHR-JavaITS.pdf > > - Although there is a lot of Java-code, but it represents a previous > version, and there is no guaranteed effort that it will be up to date > with the official Openehr-Eiffel-code. > It can be used as is, but for own risk for missing the project > developments. this is correct, it is not up to date. The intention is that it will be brought up to date very soon after the Feb 1 publishing of Release 1.0, probably by my group at UCL in London. > > - One can say, the Eiffel-code, as Thomas states somewhere, is the > case-tool, it represents the formal state of work/definitions. > One can create dotnet-libraries with it, which is already done. I can > load them in my Visual Studio and Delphi.NET. But I have no way of > checking if there is something happening behind the > interface-properties, or if they are just there as placeholders for > later use. My knowledge of Eiffel is really not enough for judging the > source-files. are you talking about the ref_impl_eiffel repository? You don't have to use that if you are not interested in Eiffel. But I don't know what you mean by "interface properties" above... > This is a confusing and maybe conflicting situation. > Because the code is at the same time case-tool storage, it serves two > purposes, which can for an outsider be confusing. > In a case-tool there is no need to write code behind the properties of > a class, one does not want to do that because code-writing is another > kind of job then software-architecture. A case-tool is a tool for an > architect, a designer, not for a programmer, although those two > professions can come together in one person, an outsider can never be > sure who was talking here behid this particular property or method. From my point of view, it is very simple. We express the openEHR models in Eiffel, which is a nearly pure OO environment, and we compile the model to get code. If you write code into the routines, then it is the same as programming. That's the whole idea seamless software development. We then build executables on Windows (.exe or .Net assembly), Linux (we're not doing this yet, but you just recompile on Linux to get an executable) and on the Mac (we have done some initial recompiles of the ADL workbench on the Mac, but there are some GUI anomalies to be solved). But all this is only relevant if you want to have any contact with Eiffel. In Java-land I suggest that the best thing to do is to work with the Java classes, and in .Net-land, the Ocean Informatics kernel will be open-sourced at some point. Not all these things are ready yet - the major delivery milestone at the moment is Release 1.0 of the specifications. > > - There are no example implementations of a complete openehr-system on > this website, does this mean that there are no open source > implementations? > Only parts can be found, which are interesting pieces of work, but the > things do not come together now. that's is true. To my knowledge, there are no complete open source implementations. That will take time. > > - Are there any known closed source implementations which run fine? You can see the list of (some) openEHR projects at http://www.openehr.org/projects/t_projects.htm > - Can the experienced programmers be hired? > - why is the ITS and knowledge coming from the closed source-projects > not returned to the project? "Give and Take" is the idea of open > source which I like. well, that is always up to the individual projects. Official openEHR.org projects (i.e. the ones you see under the website "project" link) are all completely open source. > > This are very important things for me to realize, because it means, if > I am right, there is no way now to implement openehr in a live > application open source or commercial for low cost.. well, that is probably literally true today. However, implementation efforts will accelerate markedly after 1 Feb, so I would expect that you will be able to re-use large parts of up-to-date code in a few months time. We have to realise that a lot of time has been expended in a) staying connected with the standards community b) writing good-quality specifications and testing them and c) developing the underlying theory in the first place, which has been quite challenging. So openEHR is not like mot of the other open source projects that are far more advanced in implementation, but have no standards connection, no published models (you would generally have to read the code; Corbamed applications are an exception), and generally no theory-based solution for quite a lot of the more difficult problems that remain to be solved. > Building an implementation at this stage means one has to rebuild the > complete system, and in this way contribute to the ITS-part of the specs. > Maybe a tool can be build which generates C# and Java from > Eiffel-code, but for now, that is not the case. Keeping up with the > formal definitions is a matter of re-typing the sources and guarding > the developments very well. When this is true, it is, sadly, not > suitable for the project I am thinking of. There is not a lot of money > to help build a system on a uncertain and lengthly time-schedule. > In this way, if I am right the promise of a low maintenance EPD is not > yet forfilled. well, even nice low-maintenance, open source things still cost a of lot of money to actually build;-) > > But the possibilty exist then I am really missing important parts > which prove that I am very (or a bit) wrong, and it is very well > possible at this moment to build a low cost implementation for a > project which has to be up and running in a few months. If this is the > case, I can donate my thinkings and workings back to the project. Code > written in other languages, db-schema's, interface-schemas, etc. I would expect that you can use an up-to-date Java kernel within 3 months. We are testing the current kernel with hibernate right now. The open-source .Net kernel will be somewhat longer. You may choose to go another route - using software in a more advanced stage of development, but in most cases I think you will find that the data and components will only interoperate amongst themselves and won't support archetypes or templates. - thomas beale
