> I can only agree here. I think the remedy to this problem is to split up > the work into smaller manageable pieces that are of greater interest to > the community because they can be shared. this all boils down to knowing > project/design politics. examples: > > viewing pictures: done. can you extend existing programs? Any sane practice management system would use an embeddable of addressable image viewer component.
> special rendering: fork a library if possible, data visualization is > always in need Forking is likely not a good idea. > image filtering: used everywhere. fork a library Same here. > dicom server connectivity: need only be done once and right Likely already done several times. "Doing DICOM" is not as trivial as it sounds. > managing dialogs and forms specific for a clinic: we have needed a > generic filemaker/msaccess replacement for a long time. See, many people wouldn't want to entrust their medical records to msaccess. I cannot properly comment on filemaker. What one really wants is a client/server architecture with a "real" database. > make one that > can be embedded in special purpose programs. The horrors of inter-client record locking. Crashing the app crashes the data access layer which results in locks not being properly released. Shudder. > then most of the project > specific code left will just be data and form declarations The devil is in the details: "just", but, yeah, the approach is reasonable Whether the approach is feasible - well, that seems to me like saying that "people better use Unicode for handling text". Karsten -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
