Re: dentist software
> 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
Reply to: