On Wed, 2005-07-27 at 17:12 -0400, Mike Lieman wrote: > > > On 7/27/05, Todd Berman <[EMAIL PROTECTED]> wrote: > > > I've only seen ONE Desktop Linux deployment which worked > out. That > > was in a very tightly controlled vertical application > environment for > > reserving and dispatching limos. > > > > Healthcare seems to be a fairly tightly controlled vertical > application > environment as well. Obviously not to the same extent, but far > closer > than your average home user. The hard part is the required > applications > (CPRS, VistA Imaging, BCMA, GUI-Vitals, etc), but that is a > hard > *solvable* problem. And if you go crossplatform, its not an > issue either > way which platform is being used. But the option exists in the > future to > allow for the platform to be migrated without the application > changing. > > I don't believe that the applications part under emulation is > solvable. Perhaps for one, maybe for most, but there will be an > application that is necessary which won't work. Or will work until an > upgrade comes out which uses the newest library, which chokes the > emulation layer. > > That's just MY opinion though. >
Oh, im not talking about WINE at all. We have a real, native, xplatform client. Not using WINE. > > > Now, if there was a WEB based VistA client, running that > under a > > browser under linux would likely be productive. Maybe > thunking > > through a J2EE app server? > > > > But now we're adding needless levels of complexity. > > > > Now, would you mind explaining how a web based clinical > application > running under linux is feasible, but a native one is not? > > > If it is feasible to run the web based version, then obviously > the > native one is feasible too. > > A rich client is not a bad thing in this situation. > > That's my other hangup. I think rich clients suck. I nice, W3C > compliant web-app would work in pretty much any browser client, and > that puts all the work on the server, where it belongs, so you don't > have a whole lot of browser dependencies. If you're going to code > around that, might as well just stay with a native app. > webapps are kinda hard to get the interactivity (easily) that you can get from a rich client. But that is differing of opinions. Regardless of fat/thin client, there is no reason a thin client accessed via Linux is any more/less viable than a rich client. > > We're pretty much stuck with CPRS, and it's target client is > Windows. > > > > But we aren't :). > > > Well, as I understand it, and correct me if I'm wrong, WINE requires a > Windows License also? No, WINE does not. But as I said, no where in our application is WINE involved. It is a xplatform application that looks and feels very native, and has binary cross-platformedness (is that a word?). Basically, we take the binaries built on linux, and can run them on win32, osx, and linux w/o any issues at all. --Todd ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
