[Twisted-Python] Large project (IMS) architecture

Rick Richardson rrichardson at eti-main.enabletech.com
Wed Jan 15 15:47:05 EST 2003


I have had the task of the architecture of a lab information management
system.  If you're not familiar with a LIMS it basically tracks a sample of
something, be it a soil sample, a solution generated in a lab, whatever,
through its creation/logging through instrument testing, analysis,
verification and disposal.
It will be a replacement for our current project which is written currently
in C++ Builder 4, is about 1900 source files, 52 applications and.. approx
180 different screens/docked-panels. 

One of the challenges is the heavy relationships between all of the
different entities in the database, as well as some meta concepts of
batching and QC. 
Also the there is the maintenance of the overall system as well as roles of
admin/employee/customer. 
Much of the current app is redundant and could probably be reduced to about
60 screens that do perform quite a bit of computation of one sort or
another. 
This is also a somewhat distributed system, having a single system (either
client server or p2p) used on a multitude of desktops, possibly
geographically seperated.

My vision for the project is to, first off, create an Information Management
System, then customize it into a Lab IMS. I want to take a single (or very
few) screen approach that is data and context sensitive. So that it will
dynamically create most of the screens, leaving  custom development for only
a handful of computationally intensive tasks that still take advantage of an
sweet component structure. 

For this task I turn to Twisted. Partically because I'm enamoured with the
way that it takes advantage of, and complements pythons dynamic nature. And
partially I think because it is so large and amorphous that I'm sure there's
a solution somewhere in there for me. 

My questions: 
In what areas should I begin looking for components that will help me?
Is a single, dynamic screen approach reasonable?
What is people's preference? A centralized object center and RMI? Or purely
central data and all logic on the client?

I know this is a rather vague request for information but anything is
helpful.

Rick Richardson
Quidquid latine dictum sit, altum videtur.
(Anything said in Latin sounds profound.) 





More information about the Twisted-Python mailing list