oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

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