[Oship] Recent re-factoring to Grok was: RES: openEHR Terminology source
Hi Sergio, Thanks for permission to move this to the discussion list. I will leave your email intact and reply below it. On Wed, 2009-03-18 at 09:04 -0300, Sergio Miranda Freire wrote: > Hi Tim, > > I installed the latest version and started to look at the code. > In relation to the termserver, as far as I could see, you implemented > a term > server to solve your immediate problem, but it does not follow the > specs. > I mean, it does not implement the interfaces specified in the rm > terminology > package. Do you agree? > If yes, I will refactor my original implementation to adapt your > code, but > also implementing those interfaces, ok? > > Another point is: I don´t know the reasons why you collapsed all > classes > from a top package in the rm into a unique module. > The folder hierarchy got more simple, but at the same time, each > module got > much bigger with a lot of classes. For coding and debugging, I prefer > the > previous arrangement. But I would like to hear from you. > > If you think it to be appropriate, feel free to move this discussion > to > list. > > Cheers, > > Sergio > I'm going to reply to some specifics and then give the overall view as a summary. You are correct that the terminology server that I have implemented doesn't follow the software specifications. The reason for collapsing the code and for the what may appear to be strange arrangement of Interfaces and Implementations of classes is this. I am certain that you noticed over the past many months that I had complained about circular imports? This was primarily caused when two interfaces needed to be defined as an attribute in each others interface. There were several of these and they almost always occurred within the same package. I knew of some of these issues when we were using Zope3 by itself. When we switched to Grok; the martian module (code analyzer) runs at every server startup. The server simply would not start under Grok. These Grok tracebacks helped me see just how serious the problem was and that they almost always occurred within the same module. By flattening the hierarchy it eliminated a lot of imports. Then I needed to arrange the interfaces and classes so that they were loaded in the correct order. After about three days of this re-arranging it finally runs and works correctly. Back to following the specifications exactly. You may recall that I have made a few comments about the duplication of functionality between what is defined in the specs and what is already available in Grok/Zope3? If we develop the software exactly the way the specs read then there is very little if any need for Grok/Zope3. This isn't a good open source development practice. There will need to be lots of new code written and tested (for no good reason that I can see). My goals are (and I hope that they match with everyone else): 1. Be data compliant with any other openEHR based application. 2. Deliver a product that eases the entry point for developers into the openEHR world. To be data compliant then the data classes have to match the specs and be able to express the constraints defined in an ADL archetype representation. We are doing that. Though we will use grok.Model and grok.Container as mixin classes where appropriate in order to attain goal #2. If anyone wants to develop a pure Python, hand coded implementation that exactly follows ALL of the specifications then they should use the openehr library that I left in SVN on openEHR.org I took my name off of that project because I know that I will never touch that code again. Anyone is welcome to take it over, just contact Thomas Beale. Besides the coding you are going to need to do you will also have to figure out how to solve the circular import issues that exist because *I DID* originally follow the specs. As far as I can see; the things that need to follow the specs exactly are outward facing things. EHR Extract, AQL interface, data compliance and integrity. What happens INSIDE the application is not an issues as long as these other requirements are met. I look forward to all discussions on these issues. Sincerely, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **************************************************************
Attachment:
signature.asc
Description: This is a digitally signed message part