Re: Scanning and Retrieval of Images - not VLIDB

In article <43p99o$hh4@cssun.mathcs.emory.edu> p.botcherby@umds.ac.uk "Peter K. Botcherby" writes: > The requirements are straight forward enough - the ability to > control the scanning and storage of the images under the clients > they relate too and then to be able to retrieve, display and > possibly annotate the images before printing, if required. But be warned: with imaging, as with any other system, requirements will mutate and grow... > Storage requirements are modest - initial estimate 25 Gb but ongoing > at an even smaller rate of approximately 2.5 GB per year. The data > does not permit very much OCR. [ Jack - can I coin the term SIDB :) ] > Would appreciate your comments on Plexus, Class libraries for > New Era for handling images or any other alternatives. The big thing about Plexus is that it's been around (it's from Purley!), so it's quite stable, and if you know 4GL, you'll have no trouble in working with it. I suspect that integrating class libraries with NE could be a bit of "bleeding edge" stuff, but it would certainly be an interesting experience. There are other C libraries around, which might not be as elegant as class libraries, but would certainly allow you to get the job done (Kofax springs to mind here.) > Also as the amount of storage required is modest what would be the > implications of using Raid storage arrays, purely for the blobspaces, rather > than have the additional costs of going Optical. I would go for disk, myself, although please note: > But be warned: with imaging, as with any other system, requirements will > mutate and grow... :) All IMHO, of course. HTH, Spokey the Wheeler------------------------------------------------------------- "Billy Boy" - das aufregend andere kondom! Carter - the Unstoppable Sex Machine / Wheeler - the Unstoppable Mail Machine!