David Forslund wrote: > > Many of the healthcare problems involving linking heterogeneous systems > together involve > complexity. Opensource projects need to address this > complexity. Writing a kernel > in 5 languages is not the way to address this complexity and probably make it > even worse.
Perhaps, which is why my original question was about interfacing the OpenEHR kernel written in Eiffel to other languages, not re-implementing it. I was trying to get an idea of the amount of work involved in these interfacing tasks. By "interfacing", I mean the wrapping of OpenEHR (or whatever) to make its use seem "natural" from the developer's language of choice. Of course, re-implementing OpenEHR in a range of languages is the ultimate method of doing this, but such re-implemntation is only a good idea if the OpenEHR kernel is quite simple (where, all things being equal, simpler is better). If it is not, creating language-specific wrappers for a single Eiffel implementation might be more sensible. That's what I was asking Thomas about. Tim C > Although the OMG documentation may be long, it don't think it is > any less digestible than the current OpenEHR documentation, just > different. This is > not intended as a negative on the OpenEHR documenation, either. > > Dave > > At 09:39 PM 10/27/2002 +1100, Tim Churches wrote: > >David Forslund wrote: > > > > > > I don't understand all this discussion about implementation languages. > > > We need the API in a platform and language independent form and then > > > we don't have to worry a lot about the language except to make sure > > > that the implementation language works on the platform we choose to run on. > > > The OpenEHR should be made to conform to open standard interfaces (such > > > as those of the OMG HDTF, and which it is very close to anyway). > > > >I hope that the OpenEHR API is a bit more digestible than a typical OMG > >document. Yes, I acknowledge that exhaustive specifications > >which run to hundreds of pages do have some utility, esepcially for > >large commercial system vendors, but most open source projects are > >resource-constrained, and if OpenEHR is to be useful and used in such > >projects, > >it needs to be simple enough for individuals to get their head around in > >a > >few days of effort. Or at least, there needs to be a version of the API > >documentation which fulfils this need. > > > >Tim C
