Re: [Hardhats-members] California's Prisons lack EMR
On Sun, 2005-07-03 at 13:20 -0700, Gregory Woodhouse wrote: > Have you ever considered what would happen if you tried to put a > dollar figure on the amount of effort that is expended right here on > this list in trying to make Vista work in a non-VA setting? That > effort is not free, and any effort to evaluate the cost > effectiveness of Vista as a solution needs to take that into account. > Note that I am NOT saying that Vista isn't a cost effective > alternative, only that we have a tendency to (sometimes considerably) > underestimate how much it costs to implement Vista in a new environment. > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "Design quality doesn't ensure success, but design failure can ensure > failure." > > --Kent Beck Yes, absolutely it is not free. But it is a one-time sunk cost. Well, in theory. There appears to be three types of work in making VistA work in a non-VA setting. #1) Writing code to remove certain VA assumptions that are not as needed outside of the VA, like Agent Orange stuff, changing from using SSN as a MRN to a more realistic MRN. #2) Writing code to interface with existing systems that you see in a real 'in-the-wild' system. #3) Writing code to provide functionality that is not as important in the VA systems, like pediatrics, etc. All 3 of those are one-time costs, absolutely #1 and #3. #2 is interesting, because it is a lot of different sunk costs, as you have to interface with nearly limit-less potential number and combination of systems. However, this can be solved on a system by system basis. Not attempting to marginalize the effort, just making sure it is stated that these are things that have to be done regardless, and once finished, benefit everyone multiple times. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] CPRSchart not connection from remote clien t
On Wed, 2005-07-20 at 12:36 -0700, Tomlinson, Steven B wrote: > Just as a caution to anyone attempting to use CPRSChart/VistA in thsi manner > ... all patient data as well as Access and Verify codes will be sent through > the Internet in clear-text. We wrestled with this problem for several months > and never got a HIPAA compliant solution without resorting to using a VPN or > Citrix. > Is SSL not HIPPA compliant? --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] CPRS HTTPS (was CPRSchart not connection...)
On Wed, 2005-07-20 at 14:22 -0700, Jim Self wrote: > I wonder, has anyone given serious thought to having a CPRS client connect to > the RPC > broker via HTTPS (HTTP + SSL)? That would seem to me to be the ideal solution > for > connecting internet accessible services. > That is basically (well, a bit simplified way of looking at it, but close to the same) what we are doing, so I was curious if for some reason SSL has been thrown out as not HIPPA compliant for some reason or another. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] CPRS HTTPS (was CPRSchart not connection...)
On Wed, 2005-07-20 at 15:25 -0700, Jim Self wrote: > This sort of approach would undoubtedly simplify many things. Since SSL is > *THE* secure > protocol for virtually all secure web services, I imagine that it was simply > overlooked > not rejected. > > Could you give us more specifics as to what you (medsphere) are doing and is > it available > as Open Source? > We have implemented 2 things, a crossplatform version of CPRS that runs, and has been tested, on Windows, Linux and OSX. Our goal is to both modernize CPRS in general, and to allow us to integrate and expand on the GUI functionality offered. This application talks to VistA through a piece of middle-ware, that publishes a standards-based SOAP Web Service API instead of RPC calls. This API is available over a HTTPS connection, and the middle-ware then speaks directly to the VistA server, over a lan connection (thus isolating the VistA server from the internet-at-large, and allowing remote connections in a HIPPA compliant manner). We are in the midst of heavy discussions about how to open source the various pieces involved. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] CPRS HTTPS (was CPRSchart not connection.. .)
On Thu, 2005-07-21 at 15:45 -0400, Joseph Dal Molin wrote: > Sounds like M2Web...but I may be wrongit uses Apache.. > > J. The difference is that our middle-ware publishes a SOAP API that can be used by any SOAP aware client (And basically every language out there has a SOAP library of some form or another). This allows us to write a rich desktop client using any platform/language, or a web-app, or a mobile client, or anything that can speak SOAP. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] CPRS HTTPS (was CPRSchart not connection.. .)
On Thu, 2005-07-21 at 16:31 -0400, Joseph Dal Molin wrote: > ...is it correct to infer from this and your earlier post that you have > rewritten CPRS? > > J. Yes, it would be correct to infer that we have a crossplatform client that provides the same feature-set as CPRS. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] CPRS HTTPS (was CPRSchart not connection..
On Thu, 2005-07-21 at 16:25 -0500, [EMAIL PROTECTED] wrote: > > > > On Thu, 2005-07-21 at 16:31 -0400, Joseph Dal Molin wrote: > > > ...is it correct to infer from this and your earlier post that you have > > > rewritten CPRS? > > > > > > J. > > > > Yes, it would be correct to infer that we have a crossplatform client > > that provides the same feature-set as CPRS. > > > > --Todd > > Todd, > I certainly don't want to imply distrust for your statement, > however, I'm sure most of the people in this mailing list > will ask these questions themselves, so I would like to > verbalize what many are thinking... > Absolutely understandable. I am an old-hat (well, kinda old ;)) to the opensource world, so I am aware how cheap talk is. There is no offense taken here. > Of course, the following questions can be answered by saying you > actually read the CPRS code and re-implemented all of it, but in > case you didn't actually do that, I'll bring out some of the capabilities > of CPRS as line items. > > Does that feature set include making orders for medication, lab, radiology, > and generic free text orders ? > Yes. > Does that feature set include progress notes, templated as well as free text? > Yes. > Does that feature set include graphing vital signs as well as their data > entry? > Yes. > Does that feature set include reporting on lab results and demographic > information about the patients? > Yes, If I understand the question correctly. I assume you mean the functionality in the Reports tab on CPRS. > Does it include reporting on a coversheet the active problems, allergies, > risks and other postings, clinical reminders, active medications, recent lab > results, vital signs and appointments for the currently chosen patient? > Yes. > Does it include reminders for physicians about signing unsigned orders, > periodic occurences such as vaccinations, diabetic foot exams, and other > recurring care episodes? > Yes. > Does it include patient problems by name, with associated ICD-9 codes? Yes. > Does it record patient care encounters with date, time, location, provider > and diagnoses? Yes. > Does it associate progress notes with those patient care encounters? > Yes. > Does it allow recording of vaccinations, and other recurring care episodes? > Yes. > Does it notify the doctor when drug interactions occur with allergies, > foods, or other prescribed drugs? > Yes. > Does it do most or all of these through definitions on the server side > of a VistA system? > Yes. Exactly the same as CPRS. > Well, I'm tired of typing and this should provide an initial checklist > that you can answer to tell us more about your system > > I would assume you are doing this with some kind of http connection which > is impressive in and of itself. As Jim Self mentioned, the HTTP RPC Broker > is something that has been on our "to be done" plate for a while. > > David > Now, to make sure there is no misunderstanding, we are in the final stages of our initial implementation. The goal of our initial implementation is an application that operates exactly as CPRS would (well, excluding the minor bugs here and there ;)) before we start implementing and integrating new functionality. Some of these pieces are still undergoing finishing touches, but the functionality is a) all planned to be completed and b) all very close to completion. But everything listed above is either 100% functional or 99% functional. For example, we have finished reminder dialog support just recently. The transition from VistA's binary RPC broker to the SOAP broker has not been difficult, absolutely the difficulty faced so far is implementing the rest of CPRS. As you most likely know, the communication layer in CPRS is relatively simplistic. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 12:48 -0400, alric wrote: > What ever happened with getting CRPS running under CrossOver Office? > Not to be negative to that potential idea, but I know that delphi apps are still very much unsupported running under wine. They just recently (in the last cpl months) made it so menus actually work in recent delphi apps. I am not sure how much mileage you would get out of such a solution, and it absolutely does not seem deployable in a hospital, at least to me. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 09:54 -0700, Greg Woodhouse wrote: > Delphi components are ultimately based on ActiveX/OLE which may be the > impediment to using them under Wine. Out of curiosity: Does anyone know > if the same problem occurs with VirtualPC (a commercial product)? > My understand is that VirtualPC is more like VMWare than Wine. So it should work fine, as you would have a real install of Windows. Obviously VMWare works fine, I use it every day for compatibility testing between our crossplatform CPRS-work-alike client and CPRS itself (As I don't use Windows as the primary OS on any of my computers). --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 13:02 -0400, Nancy Anthracite wrote: > 1.0,23.15 did not get fully debugged and until there is funding for the > Crossover Office folks to continue their work, things are on hold. > > CPRS had to be modified to allow what was done to be done, and therefore both > a newer CPRS and one which is unmodified working with Wine is what we would > be shooting for, a bigger job than what was done in Boston. > Again, not to be negative, but why? Crossover Office is a commercial product, and Wine itself is notoriously hard to install properly. Most distro packages of Wine are 1) old and 2) misconfigured (according to a couple of friends who work at Codeweavers). Specifically I have heard that the debian packages are very difficult and not easy to use. I think attempting to get CPRS to run under Wine and/or cxoffice (Yes, I know they are based on the same product, but cxoffice seems to get the COM fixes before Wine gets them, and that will be a huge stumbling block on CPRS running under a windows emulator on linux). Not to mention that Wine doesn't work outside of Linux + x86. You can't run it on Linux + PPC, and I believe it doesn't work at all well on other OSs like FreeBSD, etc. The amount of time/energy put into making CPRS run on linux through these methods seems like stop-energy to me. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 13:31 -0400, Nancy Anthracite wrote: > The Crossover office folks would fix it to run on Wine were they to get the > funding. That was the plan, it just never got that far. They are eager to > work with us again if things work out and I hope they do as we had a great > time working together. But that doesn't answer the real issue. Is a version of CPRS limping along under Crossover Office/WINE something you could stand in front of a CIO of a hospital, look him in the eye, and in good faith offer as a viable option for a desktop Linux deployment? It isn't for me. And if that isn't the goal, and the goal is just to be able to run *something*, then redirecting those funds towards something better, and suggesting VMWare or a similar solution sounds like a better idea. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 14:00 -0400, Nancy Anthracite wrote: > Well, since it doesn't exist yet, it is moot, but when it does it will be > thoroughly tested and at that point, then it can be presented. It would be > the intention to pass Class I testing. I can't think discussing something that you would be spending money on is moot. I guess the question is how much money do you think it would cost to get something that would "pass Class I testing" and allow you to comfortably suggest and support it. I would think it is more money than makes sense to get a solution that is in no way viable in the long term. I mean, you get CPRS running once, great, now every update to CPRS you have to fix bugs that are introduced, and you don't have the ability to easily add more features and functionality to the client. These are all things we looked into before investing our time and energy in a clean version of CPRS that already runs cross-platform, speaks over SOAP + HTTPS, and be easily translatable. Just trying to add a different perspective to the matter at hand. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 13:56 -0400, Joseph Dal Molin wrote: > Todd, > > Had you been in Boston to see the progress and results we saw in the > very short period of time that the experts worked on this solution you > would probably have a different opinion...CPRS working under WINE will > be a viable option, it just needs a bit more work. VMware while an > alternative is expensive and more complex. > Oh, I agree. However due to concerns I mentioned in another email, I dont see how it is actually being considered as an actually viable long-term option. I have no doubt you can get version X of CPRS running under WINE for Y dollars. But that isn't the issue at hand, in my opinion. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 13:59 -0400, Joseph Dal Molin wrote: > Perhaps this whole discussion is moot in the long run as the VA is > rewriting CPRS in Javawhere does that leave someone who decides or > decided to write a new version of CPRS?? Already done. --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 14:18 -0400, Nancy Anthracite wrote: > Well when what you have is available as open source free, then it will not be > necessary to discuss other solutions. > As I said before, we are in the process of open-sourcing pieces of our work. I have been involved in a decent amount of meetings over the last couple of weeks that show real progress towards something that will be beneficial to everyone. > The VA is also producing a solution that is cross platform and Jim Self is > working in that direction as well. Until then, I see not reason not to > pursue this if the funding becomes available. There are developing counties > and perhaps US users that will be happy to have. For developing countries, what is the current plan to translate both the Delphi CPRS UI, and the strings that are returned from VistA? --Todd --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
On Wed, 2005-07-27 at 16:54 -0400, Mike Lieman wrote: > On 7/27/05, Todd Berman <[EMAIL PROTECTED]> wrote: > On Wed, 2005-07-27 at 13:31 -0400, Nancy Anthracite wrote: > > The Crossover office folks would fix it to run on Wine were > they to get the > > funding. That was the plan, it just never got that > far. They are eager to > > work with us again if things work out and I hope they do as > we had a great > > time working together. > > But that doesn't answer the real issue. Is a version of CPRS > limping > along under Crossover Office/WINE something you could stand in > front of > a CIO of a hospital, look him in the eye, and in good faith > offer as a > viable option for a desktop Linux deployment? It isn't for me. > > 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. > 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. > We're pretty much stuck with CPRS, and it's target client is Windows. > But we aren't :). --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CPRS & Crossover Office
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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: Open Source CPRS using HTTPS & SOAP
On Wed, 2005-07-27 at 15:00 -0700, Jim Self wrote: > Todd Berman wrote: > >As I said before, we are in the process of open-sourcing pieces of our > >work. I have been involved in a decent amount of meetings over the last > >couple of weeks that show real progress towards something that will be > >beneficial to everyone. > > Can you say yet what parts will certainly be released and what parts will not > be or are in > question? If there are questions regarding the server or middleware, would > they be eased > by development of the RPC function on M2Web? The current thinking is to release both the middle-ware and the client. However, the licensing on the two would be very different. We would like everyone to be able to take advantage of the middleware, as it does provide a *lot* of needed functionality (and more going forward). So I believe the current thinking is GPL on that. However, the client itself is much more of a investment for us, and I believe currently we are thinking about going with something like a non-commercial license with very easy licensing terms. There are several reasons for this, which I wont go into deeply here, but mostly it comes down to preventing a company like SAIC to go ahead and snag what we have done. However, this is all speculative at this point, and could change pre-initial release and post initial release. If you have any licensing suggestions, feel free to bring them up. We are still attempting to work through various issues while continuing to actually get *real* work done. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] TIU Interface for Document Scanning
On Tue, 2005-08-09 at 16:46 -0600, Cameron Schlehuber wrote: > The whole Imaging GUI is far more sophistication than is required. The key > parts to having a relatively simple substitute for simple document images is > to be able to scan and post the IDs and location of the image to the IMAGE > file 2005 and post the IEN for the entry to the pointers in the respective > packages, such as with a TIU note. Then recover the IEN when desiring the > image in its context and retrieving the relevant information from file 2005. We decided to go that route for simple document images, although we integrated it with the document browsing GUI. A recent screen-shot of the system looks like this: http://www.medsphere.com/images/imaging_voe.png This screen-shot was taken running against a VistA-Office EHR server on my Linux workstation. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] TIU Interface for Document Scanning
On Tue, 2005-08-09 at 22:07 -0400, Nancy Anthracite wrote: > This appears to be a solution that is integrated into your CPRS replacement, > correct? Yes. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Sun, 2005-09-04 at 11:15 -0400, Kevin Toppenberg wrote: > I am working on document imaging. And more specifically, transferring > images (i.e. binary data) to and from a Windows client, written in > Delphi pascal. > > I have become convinced that transferring the file through the RPC > Broker is the way to go: > > 1. It doesn't require the server to set up any sort of file server to > the client (i.e. ftp server, or exposed file system) > 2. It avoids potential security problems, such as users requesting > images/files that they should not be accessing. The server function > can screen the client requests > 3. It would use the already-established connection--which may be a > client outside the server's usual network. With the new xinetd > connection method, it can no longer be assumed that the client already > has access to the server's local network. > > Having decided this, I therefore need to establish binary file > routines on the server and with the RPCBroker. To this end, I have > written the following code: > > 1. BFTG -- BINARY FILE TO GLOBAL. It works just like the kernel > function FTG, except that it handles binary data. And FYI, M globals > appear to hold binary data with no problems. > 2. GTBF -- GLOBAL TO BINARY FILE. Again, just like kernel GTF > 3. CPYBG -- a binary global resizer. The kernal OPEN function > hard-codes in a record length of 512 bytes. This might not be the > best size for passing through RPCBroker, so this function will copy > the binary global to a different global using a different record(line) > length > > I have then written a RPCBroker call that attempt to pass back the > binary data. I think I am writing my function call correctly, because > when I pass ASCII data, it comes through, but when I pass binary data, > it doesn't come through properly to the Delphi/Windows client. I have > yet to test exactly which part of the character set messes up > RPCBroker. It has nothing to do with the character set, and everything to do with the Delphi RPCBroker client. If you look at xwb/Trpcb.pas in the CPRS source, you will see on line (in my copy) 808 the start of TRPCBroker.Call. This code eventually uses pchCall in the same file, starting at line 973. The comments identify this as the lowest level possible RPC call w/ the RPC Broker. It looks like using anything above pchCall will not work for sure, as it is converted into a string or a string list, however you should be able to get it to work using pchCall, as that just returns a PChar. > > So to address this problem, I had decided to use some sort of ascii > armouring (encoding) of the binary data to get it to successfully pass > through--such as simple hex encoding, or even UUENCODING. > > Maury pointed out that I should post my overall purpose here and see > it I am working on the wrong problem. > > So here are my question: > 1. Is there some good reason that I should not be passing binary data > through RPCBroker? > 2. Could RPCBroker be beefed up to handle binary data? It already does. We use it to transfer progress notes in languages that use a MBCS very successfully. > 3. Any other thoughts? Mostly, I would question the need/desire to store this data in VistA, and access it via the RPC Broker. I understand the three points you made above, however it seems to me that using some form of https (with a password) accessible webserver makes this far more manageable from the client end. Also far more scalable. Tasking vista to transfer potentially large binary files down the RPC Broker connection seems somewhat like using a sledgehammer to tap in a push-pin. Not to mention not nearly secure enough for use. Great that you provide some 'security' by deciding if you will give a user a file, but you could provide the same 'security' by deciding if you will give a use a URL. But that security goes right out the window the minute you transfer that file over the unencrypted RPC connection. Of course, this is also a more general issue facing the current RPC method, so it is not specific to this issue at all. It would seem that using urls + https + authentication is the better way to go to handle this, as it does also 'solve' all 3 points brought up, but (imo) in a better, more secure, and far more scalable fashion. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Sun, 2005-09-04 at 08:58 -0700, [EMAIL PROTECTED] wrote: > On Sun, 2005-09-04 at 11:15 -0400, Kevin Toppenberg wrote: > > 2. Could RPCBroker be beefed up to handle binary data? > > It already does. We use it to transfer progress notes in languages that > use a MBCS very successfully. I should clarify. We use the RPC Broker *protocol* to transfer progress notes in languages that use a MBCS, we do *not* use the Delphi RPC Broker code. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] transfer-binary-data-via-RPCBroker
On Sun, 2005-09-04 at 11:52 -0500, John Leo Zimmer wrote: > -- Original Message --- > From: Kevin Toppenberg <[EMAIL PROTECTED]> > Sent: Sun, 4 Sep 2005 10:59:11 -0400 > Subject: Re: [Hardhats-members] Bitwise operators in GT.M? > > > Maury, > > > > I understood Zimmer's point. But I think it might introduce a level > > of complexity that would not be needed if I converted it myself. > > Also, it would lock the code into the linux platform. > > [jlz] uuencode works everywhere. PGP/GnuPG ascii wrapper would work, too. > > > But your point about whether this is the best approach for > > transferring binary data is well taken. > > [jlz] Kevin, How does VistA Imaging transfer images into CPRS? > VistA Imaging requires the use of a windows filestore, using UNC paths as far as I recall (with login/pass). --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Sun, 2005-09-04 at 16:17 -0400, Kevin Toppenberg wrote: > Notes below: > > On 9/4/05, Todd Berman <[EMAIL PROTECTED]> wrote: > > On Sun, 2005-09-04 at 11:15 -0400, Kevin Toppenberg wrote: > > > I have then written a RPCBroker call that attempt to pass back the > > > binary data. I think I am writing my function call correctly, because > > > when I pass ASCII data, it comes through, but when I pass binary data, > > > it doesn't come through properly to the Delphi/Windows client. I have > > > yet to test exactly which part of the character set messes up > > > RPCBroker. > > > > It has nothing to do with the character set, and everything to do with > > the Delphi RPCBroker client. > > > > If you look at xwb/Trpcb.pas in the CPRS source, you will see on line > > (in my copy) 808 the start of TRPCBroker.Call. > > > > This code eventually uses pchCall in the same file, starting at line > > 973. The comments identify this as the lowest level possible RPC call w/ > > the RPC Broker. > > > > It looks like using anything above pchCall will not work for sure, as it > > is converted into a string or a string list, however you should be able > > to get it to work using pchCall, as that just returns a PChar. > > > > I am away from my system that has Delphi on it, so I will have to > check the code to see exactly what you mean. But I am not following > you here. > > To my understanding, Delphi strings are stored in a different format > than the usual c/c++ (null-terminated) way strings are. They start > with a byte(s) that specify the length, and then are followed by bytes > that can hold 0-255. Thus they can hold binary data, while > traditional null-terminated strings will interpret any 0 byte as an > end-of-string marker. > > My understanding is that PChar type strings are null-terminated. Thus > I am not sure if the problem is that the RPCBroker is using Delphi > strings, or null-terminated strings. > > But I appreciate your references to the code, and I will look at that closely. > The PChar 'string' is a C style string. The issue with using Call instead of pchCall is that you are getting returned a Delphi string, and (I believe, but am not sure) a Delphi StringList, which uses embedded \r \n, \n, and \r to seperate the string into an array. By getting the PChar return, you are basically being given a byte*, which is what you want, not a TString or whatever is returned by the other calls. You might have to massage the data and play with it a bit to get it to where you would want, but that is where my suggestions below come into play (Not using the RPCBroker to transfer images). The reason I am pretty sure of this, is that the RPCBroker doesn't stop reading on a \0, it keeps reading until a ASCII EOT, #4. However, you could run into issues dealing with the returned PChar and \0, but I would have to think that this is at least a better way to start looking at solving it if you do decide to stay with the RPCBroker. If pchCall gives no joy, I would then look at strCall. Stay away from Call and lstCall, as those are going to def. cause issues. > > > > > > So to address this problem, I had decided to use some sort of ascii > > > armouring (encoding) of the binary data to get it to successfully pass > > > through--such as simple hex encoding, or even UUENCODING. > > > > > > Maury pointed out that I should post my overall purpose here and see > > > it I am working on the wrong problem. > > > > > > So here are my question: > > > 1. Is there some good reason that I should not be passing binary data > > > through RPCBroker? > > > 2. Could RPCBroker be beefed up to handle binary data? > > > > It already does. We use it to transfer progress notes in languages that > > use a MBCS very successfully. > > If you are not using the *Delphi* RPCBroker client, do you think that > you could or could not use your same code with the Delphi code? What > is different about the RPCBroker clients between platforms? > Our broker is a reimplementation, as we do not have our client implemented in Delphi for various reasons explained earlier on this list. The difference is only in the code that is used to implement it. The protocol itself is the same, and our implementation of the RPCBroker speaks perfectly fine to a FOIA VistA, or VOE, or any other server. So if there is an issue at the end of the day with getting the actual binary data out, it exists in the Delphi implementation, not the protocol itself, or on the server end. > > > > > 3. Any other thoughts? > > > > Mostly, I would question the need/desire t
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Sun, 2005-09-04 at 17:18 -0700, Jim Self wrote: > I agree. When will your solution be released as Open Source. Has it been > decided yet what > parts will NOT be released. I am not able to give a date for that release, only that it has been discussed, and we believe to have found a workable solution for the client code we have written that would allow free use of the *entire* stack, and "Open Source" (I am assuming you mean "Free Software", as the term "Open Source" is very polluted, and plenty of "OSI-compliant" licenses do *not* fall under anything I would consider open and/or free (CDDL, CPL, to name a few)) some parts of the stack. I am sure that regardless of any knee-jerk reaction to our eventual *initial* (This is a key phrase) offering as far as the 'free'ness of the client portion of our work will be offset when explanations for various decisions have been given. I hope that you, and others on monitoring this list understand that the commitment I believe Medsphere has to free software is very tangible and real. But we are a private company, and as such, must make decisions that allow us to keep doing all of this wonderful work that will enhance the VistA platform. And I while I am only a lowly employee at said company, my personal commitment to free software is a matter of public record, and I would be very surprised if it was something that could be called into question. Keep in mind, that this is not as simple (to me, as a member of the client development team), as putting a license on some code, putting it on an FTP server and calling that Open software. Free/Open software *REQUIRES* an Open development model. Nothing should happen behind a closed door. Because once it does, the license is unimportant. At least, that is how I feel. Anyway. That is basically a longwinded way of saying "I don't know the dates, its 'above my pay-grade', but I do know that we are committed to doing it, in a way that makes sense from day 1, and we are very much interested in being reactive to the needs in the future." Does that answer your question? --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Sun, 2005-09-04 at 21:05 -0400, Ruben Safir wrote: > > Anyway. > > > > That is basically a longwinded way of saying "I don't know the dates, > > its 'above my pay-grade', but I do know that we are committed to doing > > it, in a way that makes sense from day 1, and we are very much > > interested in being reactive to the needs in the future." > > > > Does that answer your question? > > > > What? Can you explain that again? Uh. I could, but without some sort of idea of what was not clear, it would seem pointless. However, I will try to say the same thing again in a different way, and we can go from there. We (Medsphere) are committed to Free Software. I am also committed to Free Software. I can safely say that most likely the entire stack will not be under the GPL on day 1. I can also safely say that the middleware portion of the client stack will most likely be under the GPL on day 1. I can safely say that the entire stack will be available for free use on day 1. Day 1 in this context means "Day 1 of Medsphere moving to an open development model for the client software development". I know that regardless of the licensing status of the software initially, we are making these decisions in what we feel is the best possible way for the long term health of *both* Medsphere and the VistA community. I also know that there is no current reason that the licensing of various pieces will be set in stone. However, we will be more interested in the long-term stability of fulltime sponsored development of the client application than a short-term PR gain by it being under one specific license or another. I can not put a date on this "Day 1". I also can not speak to any date of releases of other pieces of Medsphere's IP under any license, other than to say, most likely, it will occur before the client stack's "Day 1". Our (mostly meaning mine) demands for the open development model is far harder to support than just putting a KIDS Build of MouseMan on an FTP server and keeping it up to date. We are currently investing serious resources into meeting and satisfying all of our internal requirements for this to happen though. So there is work going on. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Sun, 2005-09-04 at 23:59 -0400, Kevin Toppenberg wrote: > Todd, I understand you perfectly. > > The question is whether to wait for the release of Medsphere code > someday/eventually, or to work on something else now. I believe it depends on your needs, and your timetables, workload, etc. I would like to believe that we will be releasing the client stack soon. However, it is not in my hands alone, and there are certain things that I feel we (the client development team) will need to support a sustainable open community project. And I know this would all be easier if we could give even some form of soft date that would at least give you a general timeframe, but I don't believe we are at that point yet, and I would rather not give any form of timeframe than give one and totally miss it by days/weeks/months/whatever with no real reason why other than because we felt the need to commit to a date that we didn't actually understand *cough*CMS*cough* --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Transferring binary data with RPCBroker?
On Mon, 2005-09-05 at 08:54 -0400, Kevin Toppenberg wrote: > The other issue. Will your solution require the two-server setup, > running SOAP (which I know nothing about). > > Obviously, I am not a software engineer, and have had no formal > training. I just want a solution that is simple and works. :-) It doesn't require a 2 machine setup. You can easily run the VistA server and the middleware server on the same machine. We do it for internal QA testing. But yes, the client does not know how to connect to the VistA server, it only connects via the SOAP api, so you will need to run both for our client to work. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA implementation in private practice
On Thu, 2005-09-08 at 11:53 -0400, Nancy Anthracite wrote: > I have sent Wendell a message suggesting that we have a telephone > conversation > to tell him about VistA and VistA-Office. Out of curiosity, because I have seen this sort of message for you about the same 2 or 3 subjects, why are you doing this? To me it seems like it would be better to either 1) Reply in email, and then when the next person asks, point him to the url for the archives, so he can read that. 2) Reply in email, and use that to start a wiki page that you can point people to. I can't imagine you want to spend an hour explaining the same thing over and over again, especially considering that this way involves more people who have varied expertise. I guess this might also be because I have never seen an open-source project before where people carried on phone conversations for basic education instead of figuring out how to have an open dialog that can be updated and published for the same purpose. --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ClearHealth and VistA cordinated effort.
On Mon, 2005-09-12 at 23:50 -0400, Ruben Safir wrote: > Perl and Python are real programming languages and PHP is a tool kit > which has gotten very popular with impatient programmers who are often > not as rigorous in their training as they could be. > Ruben. I believe the following quote is very apropos. Whatever language you write in, your task as a programmer is to do the best you can with the tools at hand. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. —Kernighan and Pike Basically, "You can write Fortran in any language". As much as I agree about your feelings with regards to PHP, I don't believe that you can fault the language for its average user. To me, that would be like blaming Ford for bad drivers, or the Internet for stupid people. Just because someone takes a tool and uses it poorly doesn't make the tool bad. Again, I am not defending PHP as a language/toolkit/whatever-you-want-to-call-it, but I don't believe you are being fair to the number of good programmers that choose to use it (I am sure there is at least one or two ;)). --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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA imaging on Windows server only??
On Thu, 2005-09-15 at 18:45 -0400, Kevin Toppenberg wrote: > I am (still) working on a document imaging etc. I had thought that I > would try to use as much of the existing server RPC's etc to avoid > re-inventing the wheel. > > But it looks like the use of "\" as a file path node separator > (instead of "/" used by linux/unix) is hard coded in. > Just Replace \ with / on whichever end you are dealing with it (this is what we do). Because they use \ as the separator, \\ will be used to escape a \, so you can just detect that and deal with it. However, if you are fully using the RPCs available, a \ will never be anything but a path separator. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: VistA imaging on Windows server only??
On Fri, 2005-09-16 at 14:13 -0400, Kevin Toppenberg wrote: > See below > > On 9/15/05, Todd Berman <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-09-15 at 18:45 -0400, Kevin Toppenberg wrote: > > > I am (still) working on a document imaging etc. I had thought that I > > > would try to use as much of the existing server RPC's etc to avoid > > > re-inventing the wheel. > > > > > > But it looks like the use of "\" as a file path node separator > > > (instead of "/" used by linux/unix) is hard coded in. > > > > > > > Just Replace \ with / on whichever end you are dealing with it (this is > > what we do). > > I think you are saying to change the slash in the RPC code, or are you > saying to change the slash used when storing the filepath and name? > No no, I was just saying to replace it when you actually call the routine that returns that string, and start to use it. Just run a simple replace either in M or Delphi depending on where you are dealing with that string (judging from your earlier emails, if you are still with your same design, I assume you are calling this from M not the RPC Broker). > > > > Because they use \ as the separator, \\ will be used to escape a \, so > > you can just detect that and deal with it. However, if you are fully > > using the RPCs available, a \ will never be anything but a path > > separator. > > "a \ will never be anything but a path separator." > I don't understand what you are saying. Do you mean that I need to > change the code? > \ is also used to escape things, like "\ " for a space. However, the way the existing imaging RPCs work, the \ is only used as a path separator, and never as an escape. That is what I meant. > My point for the initial message was not how to fix the problem, but > rather that it would be nice if it could be fixed in the future to > avoid other conflicts. I.e. use a "$pathseparator" variable Shrug, seems not needed. We have that function returning https urls, and we just swap the characters, and everything works perfectly. No need to rewrite MUMPS code. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: VistA imaging on Windows server only??
On Fri, 2005-09-16 at 17:29 -0400, Kevin Toppenberg wrote: > Todd, > > So let me see if I understand you. > > 1. From your client, you change any "/"'s into "\"'s before passing > the info to the RPC. Then, when you request the info back again, the > client changes any "\"'s to "/" before using the filepathname. Is > that right? We don't ever pass a file path to the RPC. We tell it to create an image record, and it passes back a url, then we put the file where it says to put it, and go about association. At no point do we ever pass any RPC a file path. If you need exact information about what parameters we send to the various RPCs, I would be more than happy to provide them. > > I have been picking through the code. And it looked to me like it had > code that actually checked for the existence of the file before > passing it's name back to the client. But I might be wrong on that. > If it is NOT verifying the existence of the file, then there wouldn't > be any problem. It doesn't seem to be an issue, considering the urls that get returned to us are https://blah/file/location, and I seriously doubt that this code is checking that. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: VistA imaging on Windows server only??
On Fri, 2005-09-16 at 19:58 -0400, Kevin Toppenberg wrote: > See below > > On 9/16/05, Todd Berman <[EMAIL PROTECTED]> wrote: > > On Fri, 2005-09-16 at 17:29 -0400, Kevin Toppenberg wrote: > > > Todd, > > > > > > So let me see if I understand you. > > > > > > 1. From your client, you change any "/"'s into "\"'s before passing > > > the info to the RPC. Then, when you request the info back again, the > > > client changes any "\"'s to "/" before using the filepathname. Is > > > that right? > > > > We don't ever pass a file path to the RPC. We tell it to create an image > > record, and it passes back a url, then we put the file where it says to > > put it, and go about association. At no point do we ever pass any RPC a > > file path. > > Hmmm. It would sure help if I had ever even laid eyes on this program > that I am trying to emulate. Thanks for this info. It helps. > > > > > If you need exact information about what parameters we send to the > > various RPCs, I would be more than happy to provide them. > > Yes, I would like those if you have them. > I will attempt to put something at some point soonish, its late friday afternoon, headin out of the office. > > > > > > > > I have been picking through the code. And it looked to me like it had > > > code that actually checked for the existence of the file before > > > passing it's name back to the client. But I might be wrong on that. > > > If it is NOT verifying the existence of the file, then there wouldn't > > > be any problem. > > > > It doesn't seem to be an issue, considering the urls that get returned > > to us are https://blah/file/location, and I seriously doubt that this > > code is checking that. > > So it looks like it is passing back a url for https. I had thought > that the VA was using local filesystems to deliver the file. Perhaps > this is something that can be configured one way or another. > Interesting. > That is what the VA does, but not what we do. The software allows you to specify the files root path, and a username/passwd, so we specify the .htaccess username/passwd and the root is like "https://images.site.com/images"; or whatever. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: VistA imaging on Windows server only??
On Sat, 2005-09-17 at 12:55 -0400, Kevin Toppenberg wrote: > Do you know where this https:// was stored? > > I thought that is was in field PHYSICAL REFERENCE (#1) in the NETWORK > LOCATION file. > That I am not entirely sure of. That was setup by one of our VistA experts, not by myself. I can attempt find out on Monday though. And I will do my best to get you the RPC arguments either today or tomorrow, but Monday at the latest depending on time allowed. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: VistA imaging on Windows server only??
On Sat, 2005-09-17 at 16:00 -0400, Kevin Toppenberg wrote: > I have just spent some time going through the code. I have documented > what I found out here: > > http://openforum.worldvista.org/~forum/index.php?title=VistA_Imaging_Issues > > I am fairly sure that the "https://myserver.com/"; would be stored in > the PHYSICAL REFERENCE field, as mentioned above. > > Then, if there is a longer path that is needed that should be > concatenated to this location, then it should be stored in the > SUBDIRECTORY field. As far as RPC usage, to add an image we do the following: Call MAGGADDIMAGE with a key-value parameter with the values as follows: "NETLOCABS" => ABS^STUFFONLY "OBJTYPE" => 3^1 "FileExt" => EXT^JPG "DUZ" => 8^ + (Users DUZ) "DATETIME" => 7^NOW "magDFN" => 5^ + (Patient DFN) that returns a string that is in the following format: image_ien^location^filename Note, the "'s in the above info are important, and the 8^ + (Users DUZ) for a User with a DUZ of 1008 means the string 8^1008 (Same for DFN). We then upload the file and thumbnail data to the place as directed (after converting \ to /, and changing the extension to ABS for the thumbnail data). Then an RPC call of MAG3 TIU IMAGE is called with 2 parameters, first the image_ien returned from the first call, and 2nd the ien of the document you wish to associate. Hope this helps. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Wed, 2005-09-21 at 08:50 +0530, Suchi Pande wrote: > ELSIE CASUGAY wrote: > > This whole thing VISTA-OFFICE is entirely unfair not only to the physicians > > but also to vendors. I feel like it is being controlled by some group. This > > VA software is FOIA and supposed to be open source but I have to take a test > > now if I want to support a physician's office. What if I want to help a > > clinic? Does that mean that I am not a qualified vendor? I have 20 years > > experience with VISTA and installed VISTA/CPRS for a private physician in > > 2001 down in Raleigh, NC without any problem and now I have to be tested to > > support it. > > > > Whatever happened to business opportunities? > > It is not clear what licence it is being released under. So it seems > too early to say what is going on. > > As a point of information: > > Open source is usually one of two licence styles. BSD style and GPL style. > I disagree in principal here, however that is not really germane. But for sure, there are for more styles of licenses than those 2. > The BSD style, which is what public domain comes under, allows a > person to take code and do whatever they like with it: extend it, make > it proprietary, distribute it and not release the source - like > microsoft did with parts of BSD code in their operating systems, at > least in the past. This means that there is a danger of a vendor lock-in. > Not with strong interoperability requirements, but that is neither here nor there. The other thing that BSD code allows you to do that you are missing is it actually allowed greater *developer* freedom. The list of promising open-source projects that have been doomed because of using a license like GPL is long and notable, in fact, many of the well known projects available exist because of this. As well as all of the insanity you get with stuff like readline vs libedit, etc. As far as public domain and BSD style licensing being the same, I disagree, lawyers disagree, the OSI disagrees. I'm not saying you are wrong, because with these legal issues you really can't be wrong, its all a matter of who interprets it and at what time. But the prevailing public opinion on that one does point a different direction. > The GPL style has one basic restriction - a restriction that somewhat > paradoxically *increases* freedom for the user in the longer time > scale. The restriction being that if the user decides to distribute > the program further, the source code must be made available further > too. The consequence of this requirement is that the code can be > developed further by the user, and that you can not ever be locked in > by the vendor. Again, vendor lock-in is not implicitly or explicitly solved via a GPL style license. You can still be locked into a vendor who distributes software under the GPL if no one else distributes functionally equivalent and/or interoperable software. The GPL absolutely does allow for someone else to come along, fork an application and continue a long with it, however, that is a high cost result, and *forcing* a fork by choosing a license does not actually promote any form of interoperability. You have to look no further than the various emacs history pages to see this sort of issue re: emacs, xemacs, etc. As well as this, library lock-in can be just as dangerous. The LGPL exists for a reason, and is very successfully used in many places, and the LGPL allows for commercial software to be built using it, which would for all practical intents and purposes cause this mythical 'vendor lock-in' that you speak of. > > Because of this, a lot of people, including me, regard GPL as the only > sensible code licence in the long term for medical purposes. > I can't say that I am one, I am of the opinion that both licenses have their uses in various situations, including healthcare. Choosing a license could easily be the single most important decision a project ever makes. To cover all possibilities with a all-encompassing statement is not good under any circumstances. > However, one catch is that there is no warranty in GPL licenced code > (essentially because there is no fixed vendor). > There is no warranty in BSD licensed code either. In fact, you would be very hard pressed to find any opensource license with a warranty. That is why every opensource company attempts to make its bread and butter off of support costs. Warranties you pay for, which puts you into a form of vendor lock-in. Look at the current situation with RHEL users. An RHEL user is not able to get support on anything that did not come down from the RHEL package stream. This is a very correct business decision on the part of RedHat. However, does prevent a RHEL user from compiling their own kernel and getting support. The number of RHEL support requests that get closed due to 'unsupported software' is staggering. In addition to this, you end up being forced to use RHEL only in order to actually get sup
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD, SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Wed, 2005-09-21 at 12:25 -0400, Dr. Schrom wrote: > I'm not opposed to allowing authors of proprietary software to have free rein > to market their software and support as aggressively as their business ethics > allows. VistA is in the public domain under FOIA, therefore CMS really > shouldn't > have the right to release a derivative of it (i.e. Vista-office) in any way > which restricts "public" access to it. I should have the right to install it > without vendor support. Sure, GPL projects flop, but the GOOD ones survive > largely because of "support" from communities like Hardhats. I haven't met > any of them personally, but there are some really bright people on this list, > and if the can work someone like me through an installation of VistA, I don't > feel that I want or need paid support, and I should not be required to buy it. No. That is *WHAT* Public Domain means. It means anyone can take anything and do anything with it. Which is why CMS can take VistA, and release a version of it they sell only to doctors with red hair if they want. It is a piece of software under the public domain, they are free to do what they would with it, but *you are too*. No one can force you to buy or pay anything for VistA, as the FOIA is under public domain. But VOE is a totally different beast. I believe the hope on this list is that CMS will release it into the public domain or at least a opensource license, however I am not even sure that has been confirmed. Just because software is given away doesn't make it opensource, or in the public domain. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD, SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Wed, 2005-09-21 at 10:33 -0700, Greg Woodhouse wrote: > I don't think that follows. Being available through FOIA doesn't imply > a GPL style license. Absolutely. As an aside, has there been any confirmation that VOE will be released into the public domain, or under any OSI compat license? --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Wed, 2005-09-21 at 12:26 -0700, Jim Self wrote: > Todd Berman wrote: > >The other thing that BSD code allows you to do that you are missing is > >it actually allowed greater *developer* freedom. > > Please explain. As I understand it, the only thing lost to developers in > using the GPL is > the freedom to hide the source code for the applications they distribute and > thereby to > prevent their users from carrying on with the development. We have seen many > great > products killed for various business reasons and we have faced a number of > difficult > transitions and seen many more due to organizations having become > operationally dependent > on software that is no longer supported and can't be updated. Oh, absolutely the GPL prevents that *IF YOU DISTRIBUTE* the application binary. You can still have a GPL-using application that you never distribute except in an application-server model, that you would never have to give the source code for. But, that is neither here nor there. The reason BSD allows greater developer freedom is this: Lets use a typical BSD-style license, the MIT X11 as an example. If I am writing a program under a non-GPL compat license (and this does not mean commercial, there are plenty of popular OSI compat licenses that are not GPL compat, like the Apache License for example). I can not use a GPL library or application. However, if that code was under MIT X11, I would be able to use it regardless of the license I feel is appropriate for my application/project. This is giving me, the developer, greater freedom. The freedom to use code is as important to me, as a developer, as the other oft quoted 'freedoms'. This is a huge issue with GPL libraries. Not to mention the issues of the patent-bomb GPL/LGPL clause that prevents a GPL mp3 decoding library from ever being distributed legally, where-as a MIT X11 mp3 decoding library has none of these issues. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD,SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Wed, 2005-09-21 at 18:39 -0400, K.S. Bhaskar wrote: > On Wed, 2005-09-21 at 11:45 -0500, Todd Berman wrote: > > [KSB] <...snip...> > > > > No. That is *WHAT* Public Domain means. It means anyone can take > > anything and do anything with it. Which is why CMS can take > > [KSB] Not to pick nits, but this is not strictly true. For example, I > can't take a listing of FOIA VistA and (assuming I could lift it) hit > someone over the head with it (at least, not without exposing myself to > arrest for assault and battery). It's' probably also illegal to ship > VistA to Cuba, North Korea, Iran even though it's in the public domain. > Public domain only means that I do not have to be concerned with > ownership of intellectual property when I contemplate doing something > with VistA. Any and all other restrictions still apply. Since we are picking nits just a bit, it being in public domain does not restrict you from doing that. Other laws may, but if you feel it necessary to ship to Cuba, then print it out, then run around Havana beating people over the head with it, nothing about the license restricts that usage ;). Not that I would recommend it. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Wed, 2005-09-21 at 18:26 -0700, Jim Self wrote: > Todd Berman wrote: > >If I am writing a program under a non-GPL compat license (and this does > >not mean commercial, there are plenty of popular OSI compat licenses > >that are not GPL compat, like the Apache License for example). I can not > >use a GPL library or application. > > That interpretation seems to me to be at odds with what I read from the > Apache Foundation: > > http://www.apache.org/foundation/licence-FAQ.html#GPL > "It is the unofficial position of The Apache Software Foundation that the > Apache license > is compatible with the GPL. However, the Free Software Foundation holds a > different > position"... > Yes, the FSF believes the GPL and the Apache license to be incompat. And considering they wrote the GPL, I am inclined to err on the side of caution. Plenty of apps replace dependencies due to Apache license usage. There are a fairly large number of licenses that the FSF believes to be GPL compat. This means your GPL code and someone elses can not interact. Sorry, you lose. Write a replacement library. Have fun. It is pretty bad news when it comes up. > and a more in depth discussion: > > http://www.apache.org/licenses/GPL-compatibility.html > > The issue seems to revolve around questions involving interaction between > patent claims > and copyrights that seem to be mostly moot. > > >Not to mention the issues of the patent-bomb > >GPL/LGPL clause that prevents a GPL mp3 decoding library from ever being > >distributed legally, > > That's an interesting concept I hadn't heard of before. Looking on google for > "patent-bomb > GPL turned up things like Mono and Microsoft and reference to a patent bomb > in the Apache > 1.1 license. ??? Looking for "mp3 GPL" turned up what looked to me like a > long list of > GPL MP3 players... Doesn't surprise me, Alan Cox is a huge fan of the word patent bomb, and the gnome/mono mailing list conversations are high high up as far as page-rank, they get linked too far too often. However, This is why RedHat doesn't distribute mp3 support. Here are the relevant sections of the GPL that prevent this distribution: Section 7: If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. Sorry to quote a huge chunk of text, but I believe taking bits and pieces out of context makes it harder to understand. Basically, what this sections means is that if a GPL'd mp3 decoding library is found to be violating a patent (which they all are), you can not distribute the library. This is the patent-bomb. This is also why the GPL can be bad. Don't get me wrong, I am a huge fan of opensource, and the GPL does has its place in opensource. But assuming that GPL = Good and Anything else = bad is just naive. Different licenses exist for tons of reasons, and the GPL is n
RE: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD, SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Thu, 2005-09-22 at 00:02 -0600, Cameron Schlehuber wrote: > If someone takes "Little Red Riding Hood" and just changes the word "Red" > wherever it shows up to "Green", then claims a copyright of some kind or > another on it, and someone else changes every other word "Red" to "Green" > (half red and half green), and the first person who thinks they hold a > copyright tries to take the second person to court, I doubt they would > succeed (certainly not if I were on the jury!) Just like changes to a > legitimately copyrighted work must not be simply derivative of the original > work for someone to claim a new copyright, doesn't the same rule apply to > public domain works? In other words, for anyone to have any form of > copyright hold on their derivations from public domain VistA, the changes > would have to be sufficiently significant that it was clearly a new work (to > the proverbial "reasonable person" as the courts like to refer to). > No. A work that is in the public domain is just that. Anyone is allowed to take it and do whatever they would like with it. This is in fact why companies such as Disney prefer to take old fairy tales and stories and turn them into movies. They are unable to be held to any form of copyright, and are able to do whatever they would like to the story. In fact, in cartoons specifically, this is very very common. How many different interpretations of fairy tales have you seen done by WB and Disney? Its a seemingly endless number. This is in fact exactly one *huge* difference between something that is in the public domain, and something under a BSD style license (to whoever was saying they are the same). Once something is releasing into the public domain, it is available for fair use by anyone, for anything. Hopefully this definition will make it clearer: Definition: A public domain work is a creative work that is not protected by copyright and which may be freely used by everyone. The reasons that the work is not protected include: (1) the term of copyright for the work has expired; (2) the author failed to satisfy statutory formalities to perfect the copyright or (3) the work is a work of the U.S. Government. (from: http://www.unc.edu/~unclng/public-d.htm) My understand of VOE (which could be very wrong) is that CMS is developing it with the help of outside contributors. Because there are outside contributors involved, it could be considered software that is not a 'work of the U.S. Government' and not required to be under the public domain. This last bit I am not clear on, but it does seem like the intent is to release it into the public domain. Also, that is a clear distinction. You release something 'into' the public domain, not 'under' the public domain. It is not a license, it is more like a giant pool of available knowledge and information. As far as your example, it would obviously have to be decided by a court, but under our legal system, it is a moot point, as the lawyer for the second would argue that the second work is a derivative of the public domain work, not the first, copyrighted, work. But, both the first and second persons would be exactly correct in claiming a copyright on their respective derivative works. Anyway :). > And by the way, it seems reasonable to be wrong for me to write code to a > patent that I do not hold and try to distribute that as GPL. Likewise, if > the person who holds the patent tries to collect some advantage by applying > a GPL to their own patented code, they shouldn't be permitted to distribute > such a tar-baby either. > You can distribute your own patented code under the GPL without any issue. But if you attempt to prosecute anyone for using that patent, you (and everyone else) are no longer able to distribute even *your own* GPL patent-containing code. However, because you are the author of said code, you are free to sue using your patent, and then release a new version of your code under another license. If you look into some history of the licensing behind Eclipse, many critics will explain that they view the Eclipse license (the CPL) as a patent-grab license using a semi-similar tactic. I have no real feeling one way or the other, but I will never contribute code to a CPL licensed project, nor will I ever depend on or look at the source for one, just to err on the side of caution. Anyone who writes any code is always able to re-license it under another license, regardless of what license it is under at any point. You are the copyright holder, you do control it. (Under current US copyright law, in theory your heirs control it for 70 years past your death, but because software is not yet that old, it has not come up in practice). --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Thu, 2005-09-22 at 13:19 +0530, Suchi Pande wrote: > I wrote: > >>Open source is usually one of two licence styles. BSD style and GPL style. > > Todd Berman wrote: > > But for sure, there are for more styles of licenses than those 2. > > > More explicitly, I am saying that all open source licences have > features that tend to put them in one style or the other. Licences > that tend to let a developer usurp and close the code and lock in the > user are BSD style, while licences that do not are GPL style. > That is a pretty negative way to look at the differences, but ok :). > > The other thing that BSD code allows you to do that you are missing is > > it actually allowed greater *developer* freedom. > > Yes. However, the risk for a BSD licenced software is that the > freedom of the developers is at risk if a company forks off a closed > version and adds proprietary bits to it, and tries to extinguish the > old standard. It has happened enough times with MS windows > applications taking BSD licenced stuff. > And this was a WONDERFUL thing in *MANY* instances. Why do you think the TCP/IP stack is such a solved issue on modern operating systems? Because they all use the BSD TCP/IP stack, and they inter-operate flawlessly. Yay for people using similar code making my world a better place. > Nonetheles, it is a consequence. Vendor lock-in is much *much* harder > to enforce with GPL because you cannot close the code if you > distribute the software to others. > Incorrect. In fact, In health-care, I would argue that vendor lock-in is just as easy with the GPL as it is with BSD. Lets say you write this great wonderful amazing VistA module that solves every problem ever seen or heard of. It makes this software basically 'finished' (Yes, I know, Impossible, but this is a hypothetical). So you decide, being the good Samaritan that you are, that you will release this wonderful module under the GPL. My company, lets say SAIC for grins, takes your GPL code, and then adds all kinds of more wonderful stuff. Now, under the GPL when I distribute a binary, I must distribute source. But what happens if I don't ever distribute a binary? Then I have found one of the many truck-sized loopholes in the GPL. I can now take your wonderful code, and my amazing code, and sell it to hospitals as an appliance. No binary, just a box they can't access with my software on it. It can even be on-site, I can easily ship a computer and a person to set it up, and send someone out whenever there is a problem with it. All of a sudden, I have just sold a piece of GPL code for a high price, and with my pre-existing support and sales market, I am well on my way to cornering the market, and I *never* have to provide my code back. The enormity of this industry makes such an attempt possible, and even easy. Now. I am not saying a BSD style license solves this. And sure, SAIC could just as easily take your BSD code and do the same. But to act as if the GPL 'solves' this problem is very naive. Sending a box to a customer to retain what becomes at this point a 'trade secret' is a small price to pay for a large or even mid-sized company. Sucks. Doesn't it? > > You can still be locked into a vendor who distributes software under the > > GPL if no one else distributes functionally equivalent and/or > > interoperable software. > > Yes. But if the software is at all popular, a fork will spring up. On > the other hand, forking from a closed source distribution derived and > extended from a BSD style licence is much harder. > If something is released as an opensource BSD licensed project, you can always fork from it. You can re-license code, but you can't change the license of code that is already released. Sure, you don't get access to some other companies modifications, but as we saw above, that is not something that the GPL can viably force either. > > The GPL absolutely does allow for someone else to come along, fork an > > application and continue a long with it, however, that is a high cost > > result, and *forcing* a fork by choosing a license does not actually > > promote any form of interoperability. You have to look no further than > > the various emacs history pages to see this sort of issue re: emacs, > > xemacs, etc. > > > > Yes, GPL style code forks, a design may change, but fit code survives > and you always have access to whichever code you want. Diversity is > good, gives choice, and is self-limiting. > > More importantly, the foundations of interoperability are open > standards, formats. These foundations allow compatibility (not the > same as interoperability) to be better in open source. Close off the > source, and create your own standards and formats, and we
RE: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD,SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Thu, 2005-09-22 at 09:00 -0600, Cameron Schlehuber wrote: > And as for the examples of hiding code in an "appliance" and selling -that-, > well, if I sold a PC as an "appliance" with Windows XP and didn't forward > the license fees to Microsoft, and made a big enough splash that got > Microsoft's attention, my "black box" would likely be sufficiently reverse > engineered by Microsoft to skewer me in court. The same logic would apply > to any other license where there was sufficient motivation to figure out > what was in the black box. > > Cameron. Unfortunately Cameron, Microsoft does not release its software under the GPL. And selling an appliance with their software without paying the fees is illegal. That is not the case with the GPL. There are companies *TODAY* doing just what I am talking about. It is legal (although unethical a bit IMO) but it is totally legal. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Document formats, licenses and copyrights
On Thu, 2005-09-22 at 18:20 +, Aylesworth Marc A Ctr AFRL/IFSE wrote: > No, that is also why Samba could not write to NTFS file systems for so long > and why OpenOffice could not open Microsoft Word documents until they used > xml as the storage format. Uh. I use OpenOffice every day to open non-xml Word file formats. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Re: CMS NEWS: ELECTRONIC HEALTH RECORD SOFTWARE DELIVERED TO, PHYSICIAN OFFICES
On Fri, 2005-09-23 at 13:06 +0530, Suchi Pande wrote: > Todd Berman wrote: > As much as I disagree with what you are saying (Flashroms updates (this is where the FSF wins) are distributed binary, so you do need to distribute the source)(There are companies today shipping network appliances using GPL software without releasing their enhancements, and the FSF is aware and impotent), etc etc. I see this as a publicly dead horse, we could continue to flog it for a couple more days, or just leave it as is. If you are interested in continuing this conversation (which I do find very interesting, especially considering your opinions which I find to be a bit naive (no insult meant, I just find your inductions to be rather blue-sky, and the reality is far different)), please email me privately, and I will happily do so. --Todd --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Non- Windows OS for CPRS
On Wed, 2005-09-28 at 11:47 -0400, Nancy Anthracite wrote: > I would also like to point out that there are other potential solutions that > are browser based, and a solution in the pipeline from the VA, but that will > probably not be totally cross platform for a number of years, and then you > could call Medsphere and see what they will sell you and for how much as I > believe they may have something as well. Wow. Thanks for the backhanded compliment Nancy. Yes, Medsphere does have a crossplatform (Win32, Linux, OSX) client reaching completion of development (where completion is established as CPRS functionality). We are very close to our '1.0' completion mark, just polishing some things, and putting some finishing touches on the larger areas of functionality. And we have been planning on offering it under some form of open licensing, and developing it under an open development model. We are mostly just waiting for infrastructure to replace our current development tools. We are currently using an issue tracker, file release manager, etc that are not able to be made open, so we have to figure out how to solve that. And since that happens to not be our core business (developing web-app project mgmt software, etc), it is taking a bit of time. So, yes, you could contact someone in sales here and see what we would sell you, or you could wait until we get everything put together and made available, as you would be able to use it then. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Imaging and Image filetypes
On Wed, 2005-10-05 at 04:54 -0400, Kevin Toppenberg wrote: > Hmmm. Why did someone choose THAT format? > > I don't think I have code that outputs in TGA format. So I think I > will not upload .ABS thumbnails. If the only client that you are going to use for this is your custom CPRS or whatever, I don't believe it matters what format you upload it in. We are currently uploading as thumbnails of the same type as the main image (so certain format specific elements are kept, like transparency, etc). I don't know how well VistAImaging would handle this, but since we don't expect people to be using it, it is not something we are (currently) concerned with. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[Hardhats-members] GPL loophole article
Hey, Just ran across an interesting link from slashdot that I found germane to a previous discussion on this list relating to the GPL and loopholes in it. http://news.com.com/Nessus+security+tool+closes+its +source/2100-7344_3-5890093.html?tag=nefd.hed (beware of line wrapping) --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] GPL loophole article
On Fri, 2005-10-07 at 09:12 -0400, Jim Drash wrote: > There are no "real" loopholes in GPL. Let me run through an example. > Dude. Did you even read the article? It clearly states that competitors are using his GPLd code, with modifications, but selling it as an appliance, thus not distributing a 'binary', thus not having to contribute their changes or their derivative works back. That is a loophole. And yes. The GPL has that one, and a couple other subtle ones. Believe it or not, its not perfect. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Community Conference Call
On Sat, 2005-10-08 at 18:35 -0400, Ruben Safir wrote: > On Sat, 2005-10-08 at 18:24, Dr Molly Cheah wrote: > > Why not convert to mp3 files and podcast it? > > Molly > > > > Because you need a license for the mp3 format, you get sued and then it > sucks. > You need a license if you are making money with mp3s, and not an insignificant bit of money. http://www.mp3licensing.com/royalty/emd.html This URL has more info, the very important piece is at the bottom: Note: No license is needed for private, non-commercial activities (e.g., home-entertainment, receiving broadcasts and creating a personal music library), not generating revenue or other consideration of any kind or for entities with associated annual gross revenue less than US$ 100 000.00. So yeah. Using the mp3 format for this is fine. While I am pro-ogg and pro-xiph in general for sure, calling people who use ipods drones sounds. well. stupid. And incorrectly FUDing about a technology is just as bad. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Role of SOAP?
On Sat, 2005-10-08 at 20:46 -0400, Greg Kreis wrote: > What about VistALink? Could it be used to support SOAP? Maybe the > latest version or a planned one will? > Not really. My understanding of what VistALink is, is just an implementation of the client end of the RPC broker in Java instead of Delphi. You still have to talk to the actual VistA server at some point, and the transition from VistA RPC Broker to SOAP has to occur somewhere. Also, writing a RPC Broker client really is not difficult, it is easy to do in any language in an hour or so. Creating a SOAP API out of the VistA rpcs on the other hand takes a while, you have to figure out what every RPC is returning and accepting and create complex types that encapsulate the data, and then pass that across. And that is just to give you an API that is 1<->1 with the VistA RPC API, most likely not something many would find useful (A real login session requires 6+ RPCs and that still leaves you with no patient or user information). As I have said on this list before, we (Medsphere) do have such a technology that sits on a server, takes SOAP calls and returns data back from RPC calls, wrapped up in semi-coherent data structures. We actually have server technology that allows both SOAP and an alternate form of communication, and the ability to seamlessly switch back and forth between the two. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Community Conference Call
On Sat, 2005-10-08 at 22:50 -0400, Ruben Safir wrote: > On Sat, 2005-10-08 at 20:42, Todd Berman wrote: > > On Sat, 2005-10-08 at 18:35 -0400, Ruben Safir wrote: > > > On Sat, 2005-10-08 at 18:24, Dr Molly Cheah wrote: > > > > Why not convert to mp3 files and podcast it? > > > > Molly > > > > > > > > > > Because you need a license for the mp3 format, you get sued and then it > > > sucks. > > > > > > > You need a license if you are making money with mp3s, and not an > > insignificant bit of money. > > > > You mean like all the Free Operating system distros? Its, as a fact, > and after dealing with them first hand when we did our radio show, A LOT > more complicated and difficult than that. > I find that very very interesting that you bring that up. The reason RH doesn't distribute mp3 decoders has nothing to do with licensing costs, and everything to do with patent concerns. And if you look at something like SuSE, which *does* distribute mp3 support (that they pay Real a sublicensing fee for) you will see a lot of "Free Operating system distros" that do support it. Not to mention that it is insanely easy to install mp3 support on all distros that choose not to package it on their cd-roms. Either way, I find it very difficult to believe that something like a random WorldVistA conference call would be an issue where there are thousands of people podcasting to audiences greater than 20 people on a mailing list. But, then again, I prefer the pragmatic approach over the idealistic approach preferred by some zealots. I'm sure we can just debate this for the next 3 days and 30 emails instead of actually publishing the call in either format. That seems to be the preferred route... --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Imaging: lets throw out TGA!
On Sat, 2005-10-08 at 23:30 -0400, Kevin Toppenberg wrote: > Well, I have been working unsuccesfully for a couple days trying to > come up with an open source solution for creating TGA thumbnails. > > Quick background: VistAImaging stores thumbnails with an extension > .ABS, but the file type is really TGA. > > I have worked with this code: > http://delphi.icm.edu.pl/ftp/d30free/graph64.zip > and I can't get it to compile because it appears to be trying to load > a two-byte variable into a one byte dl register. > > I have worked also with Davie Reed's Targa unit, and while it reads in > TGA files great, I can't get it to output one properly. The best I > can get is vertical bands of color with no resemblance to the desired > image. > > I know that I could just wait and the HUI or Roy's product will be > released and probably make my problem moot, but I would like there to > be an option out that doesn't require a commercial graphic component. > Such an approach means that others can run the end binary, but not > compile (or optimize) the code. > Or ours (which btw, loads TGA thumbnails w/o issues) ;) > So I suggest we approach this a couple of different ways > > 1. Add a field to IMAGING SITE PARAMETERS (file 2006.1) as follows: > -- #22700 THUMBNAIL EXTENSION (#22700 is in my numberspace) > This would contain possible entries like this: 'JPG', 'BMP','PNG' etc. > Future code could be written such that if this field didn't exist, > or had not data, would default to 'TGA'. > > 2. Agree on .BMP or .JPG as the file type for thumbnails. > > 3. Agree that thumbnails will always be in the same type as the > original document. (I believe Medsphere is doing this option.) > Nope. We happen to do that for our uploaded images, but we could easily do anything. > 4. Store thumbnails like this: ZZ01.jpg.ABS, ZZ02.png.ABS, > ZZ03.bmp.ABS etc. > > I think that option 1 would be the most 'proper' way to do it: It > would allow for any file type to be used for the thumbnail. But it > would involve modifying standard files, which would probably require > some careful thought. > I am curious why this matters. Our solution just loads 'image data'. We don't even know or deal with the format at all. We just get an array of bytes, and load it into a pixbuf structure, and our lower level image library just deals with it. I have to assume that there exists a free delphi component that is capable of the same. I know the free library we use has exactly 0 issues with this, in fact, it allows arbitrary plugin modules to add new formats very easily. > Option 3 would be the easiest. > > Option 4 might cause problems on old 8.3 filesystems, but I don't > think anyone is depending on those anymore (are they?). Plus it would > require modification of the server RPC that passes back the name of > the thumbnail. I think the code just takes the parent filename and > changes the extension to .ABS and passes it out to the client. > > All of these options, however, may cause problems is used with the > VA's full VistAImaging client. If it downloads an .ABS file and > expects it to be in TGA format, but it is not, then I don't know what > would happen. Is anyone actually using this client in a situation that would require interop with the images from another solution? It seems like a hospital would deploy one system or another, and not have multiple clients in the wild for this functionality. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Community Conference Call
On Sat, 2005-10-08 at 23:52 -0400, Ruben Safir wrote: > On Sat, 2005-10-08 at 23:00, Todd Berman wrote: > > On Sat, 2005-10-08 at 22:50 -0400, Ruben Safir wrote: > > > On Sat, 2005-10-08 at 20:42, Todd Berman wrote: > > > > On Sat, 2005-10-08 at 18:35 -0400, Ruben Safir wrote: > > > > > On Sat, 2005-10-08 at 18:24, Dr Molly Cheah wrote: > > > > > > Why not convert to mp3 files and podcast it? > > > > > > Molly > > > > > > > > > > > > > > > > Because you need a license for the mp3 format, you get sued and then > > > > > it > > > > > sucks. > > > > > > > > > > > > > You need a license if you are making money with mp3s, and not an > > > > insignificant bit of money. > > > > > > > > > > You mean like all the Free Operating system distros? Its, as a fact, > > > and after dealing with them first hand when we did our radio show, A LOT > > > more complicated and difficult than that. > > > > > > > I find that very very interesting that you bring that up. The reason RH > > doesn't distribute mp3 decoders has nothing to do with licensing costs, > > and everything to do with patent concerns. And if you look at something > > like SuSE, which *does* distribute mp3 support (that they pay Real a > > sublicensing fee for) you will see a lot of "Free Operating system > > distros" that do support it. > > > > SuSE does not have any mp3 support any longer except for the real player > if you opt in for it with a seperate licensing agreement. > Uh. Yeah. Thanks for saying what I just said. As far as WorldVistA vs NYLXS or whatever, no, I can't think either one is important in the scheme of mp3 (ab)uses. And no, you don't have to scan the document you received, as it is not really important either way. What is important is this audio is still not distributed in either format. If it is an issue of having bandwidth to distribute it, I will happily provide that if the file (in any format) is produced. The preferred route would have been for whoever had the audio 30 messages ago to post a url to it, in whatever format, and let people just deal with it either way. And I am not sure what you mean by 'univeriality'. If you mean "universality" then I can't believe you can argue that a format that multiple people didn't know of, or how to play has more "universality" than mp3. And if you didn't mean "universality", then I don't care either way. Basically, I have no desire to continue this thread (or really any other) with you, as I find you to be a bit abrasive, difficult, and generally misinformed. Also, you are quick to accuse people who are doing things (like JohnLeo Zimmer) of doing nothing while producing nothing but noise yourself (as far as I can see, and if I'm wrong, frankly, I'm past the point of caring). So yeah, to whoever actually *has* a copy of this, if you are unable to post a url to it, if you can get the file my way, I will happily provide hosting for it. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Imaging: lets throw out TGA!
On Sun, 2005-10-09 at 00:14 -0400, Kevin Toppenberg wrote: > See below: > > > On 10/8/05, Todd Berman <[EMAIL PROTECTED]> wrote: > -snip- > > > Such an approach means that others can run the end binary, but not > > > compile (or optimize) the code. > > > > > > > Or ours (which btw, loads TGA thumbnails w/o issues) ;) > > I'm excited about your code, but I don't have it in my hands right now :-) Yeah :( We are working on it. I could give a myriad of reasons/excuses as to why it is not available, but they really aren't germane. But yeah, work continues on all fronts :). > > > 3. Agree that thumbnails will always be in the same type as the > > > original document. (I believe Medsphere is doing this option.) > > > > > > > Nope. We happen to do that for our uploaded images, but we could easily > > do anything. > > I was speaking of which format to set for uploaded images. I.e. I am > creating a thumbnail. What format should I choose? You all are > currently choosing to make the thumbnail the same format as the parent > image, right? > Yup. Mostly to keep any format specific things in place, like transparency for pngs, etc. > > > > I am curious why this matters. > > > > Our solution just loads 'image data'. We don't even know or deal with > > the format at all. We just get an array of bytes, and load it into a > > pixbuf structure, and our lower level image library just deals with it. > > Maybe I am spinning my wheels again. But I have have had trouble with > the Delphi TPicture.LoadFromFile (I think it was this function) that > was using the extension to determine how to handle the data. If I > take a .bmp file (that is easily loads) and rename it to .ABS and then > try to load it, it fails. > Ew. That sucks. All the image formats we have discussed have recognizable magic bytes that allow you to recognize the format without having to resort to extension sniffing. > > > > I have to assume that there exists a free delphi component that is > > capable of the same. I know the free library we use has exactly 0 issues > > with this, in fact, it allows arbitrary plugin modules to add new > > formats very easily. > > Could you post a link to this library? > Happily. We are using gdk-pixbuf, which is a lower level library in the gtk+ toolkit. (Sorry, I kinda assumed the toolkit we were using was well known) http://www.gtk.org/ > > > > Is anyone actually using this client in a situation that would require > > interop with the images from another solution? > > > > It seems like a hospital would deploy one system or another, and not > > have multiple clients in the wild for this functionality. > > > > --Todd > > I agree that we wouldn't have to maintain complete compatibility with > hosptial VistAImaging formats. But I would like to be compatible with > everyone else. > Cool, well, whatever you end up doing, we will be able to load it, so whatever works for you :). I would recommend avoiding RPC modifications at all cost though. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Imaging: lets throw out TGA!
On Sun, 2005-10-09 at 10:01 -0400, Kevin Toppenberg wrote: > On 10/9/05, Todd Berman <[EMAIL PROTECTED]> wrote: > -snip- > > > Could you post a link to this library? > > > > > > > Happily. We are using gdk-pixbuf, which is a lower level library in the > > gtk+ toolkit. (Sorry, I kinda assumed the toolkit we were using was well > > known) > > > > http://www.gtk.org/ > > > > You probably told me that before, and I forgot. > Hmmm, that gtk looks like a huge library. I'm not sure I want to take > the time to figure it all out for this one issue. > > If your code can handle any format by format analysis instead of based > on extensions, then I think I will not use TGA. > > I'm going to use 64x64 .bmp files for now. > Kevin, One issue using a 64x64 image of any format is keeping the original aspect ratio. 64x64 thumbnail of a 600x1000 image is not going to be very useful. I would recommend using a size that allows the original aspect ratio to be honored. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] VistA Imaging: lets throw out TGA!
On Sun, 2005-10-09 at 18:13 -0400, Kevin Toppenberg wrote: > Good point. > > I am putting the thumbnails on tabs of a tab control. So it is really > just a postage sized picture to let the user know which image is on > which tab. And because of the way that Delphi does this, all the > images have to be the same size. They are stored in a TImageList, and > then the tabsheet is specified to have a given index from the > ImageList. > Ah, that kinda sucks. We are using an 'IconView', so it is just like a ListBox in Icon mode with the Thumbnails for the icon, double click to open the full image. > So to a certain degree, if the aspect ratio is off, it will be OK, > because you can barely tell what the image is at that small a size > anyway. > > One way I considered to solve this would be to figure out which > dimension had the greatest length. Then set that length of 64, and > then let the other dimension be less than 64 (and fill in the rest of > the space with white or transparent.) > We just set the height of the thumbnail to 120 pixels, and scale the width based on that. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] GPL loophole article
On Mon, 2005-10-10 at 11:21 -0400, K.S. Bhaskar wrote: > Todd -- > > It seems to me that the writer has two issues confused: > > 1. A possible loophole in the GPL. > > 2. Investigation and correction of a license violation. > > My understanding of the GPL is that selling an appliance containing > GPL'd code would constitute distribution, and the GPL does require the > source code to be made available if the binaries are distributed. > Yeah, that is incorrect (at least, could be incorrect depending on how the GPL is interpreted, but has never been proved in a court of law one way or the other, so basically is as incorrect as any murky opaque legal thing can be) though. Because the competitors are never distributing a binary to a 3rd party, they are never required to distribute source. The competitors are giving (limited) access to a piece of hardware that contains the object code, but never access to the object code itself. Obviously this is just how some people read it, not others. The GPL is basically untested, and no one, even a lawyer, has no clue how any judge would actually respond to any legal case using the GPL. I am pretty sure (but not positive) that the GPL remains basically untested in a court, and has just been used so far (successfully) as a threat. Either way, the fact remains that unless you are willing to go to court (and very potentially lose) any case like this, it is something you need to be aware of when releasing your software under the GPL. > So, it would seem that the author of a GPL'd product is seeing GPL > violations of his software, and is choosing to withdraw the source code > from future releases of his software, rather than go after the > violators. This would be a legitimate business decision for him, and > one that I can understand, although it does sadden me. > > To me, the possible loophole has to do with whether renting an appliance > constitutes distribution. I believe it would (and I certainly hope that > it would), but I'm no leagle begal. it didn't sound from the article > that rentals were what caused the author of Nessus to make his decision. > Interesting that you read it like that. Here is a direct quote from the article. "A number of companies are using the source code against us, by selling or renting appliances, thus exploiting a loophole in the GPL," he wrote in a later e-mail, justifying his decision. "So in that regard, we have been fueling our competition, and we want to put an end to that. Nessus 3 contains an improved engine, and we don't want our competition to claim to have improved 'their' scanner." Seems to be, that the author is very clearly explaining that is *exactly* why he made his decision. How else did you read that? --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[Hardhats-members] What is actually topical? WAS: GPL loophole article
On Mon, 2005-10-10 at 15:11 -0400, Kevin Toppenberg wrote: > Here is what I do know, > > The biggest arguments/discussions that we have on this list refer to > issues of windows vs linux and who's favorite open source license is > better than the other guy's. > If that is how you have followed any license discussion that has occurred on this list, I would hope you would go back and read it. It is an issue of education, not superiority. No one license is better or worse than any other, and they all have various pitfalls associated with them. At least, any post I have made has never been one of "License XXX is better than license YYY". I have contributed to open source projects under many different licenses, and don't feel any are superior. As far as posts being off topic, I would have to say that there seems to be little to no topical discussion on this list, as there is little to no topical work being done. In the many months I have been following this list, the closest thing to actual VistA development that has occurred has been your work with imaging. The rest of the posts seem to revolve around minor issues of configuration, generic M/VistA programming help, and various people's random thoughts. So, I guess, my question is basically what exactly is considered topical for this list? I have yet to even fully understand what this list is for. Is it a list for WorldVista? If so, what is WorldVistA actually doing? Where is their CVS repository where they are creating code changes? If it is a list for OpenVista the same questions apply. In general there seems to be a lot of talk from various people on this list but little to no actual progress (with some notable exceptions). I hope no one takes offense at these comments, I am just attempting to fully understand what exactly is the goal of collaborating on this list. As for my personal goal of being on this list, I was hoping to 1) further my understanding of VistA and 2) provide some form of assistance for people looking at CPRS and the RPC APIs that VistA provides. I feel that I have done both at various times. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ScanSoft graphic component and The Gimp
On Mon, 2005-10-10 at 18:47 -0400, Kevin Toppenberg wrote: > I have taken a few minutes and went through several (but not all) of > the modules in VistAImaging to see how it uses the propriatary graphic > module TGear created by AccuSoft (www.accusoft.com). > > Here are the methods and properties that would need to be implemented. > I know that the Gimp can do most of these things. It would be a > matter of creating the interface. You do realize that the gimp is not exactly a small application? And that depending on it for anything causes you to depend on a lot more. Including the toolkit that we are using, gtk+. Here is the output of ldd for the gimp tga plugin: [EMAIL PROTECTED] ldd /usr/lib/gimp/2.0/plug-ins/tga linux-gate.so.1 => (0xe000) libgimpui-2.0.so.0 => /usr/lib/libgimpui-2.0.so.0 (0xb7efb000) libgimpwidgets-2.0.so.0 => /usr/lib/libgimpwidgets-2.0.so.0 (0xb7e1d000)libgimp-2.0.so.0 => /usr/lib/libgimp-2.0.so.0 (0xb7df3000) libgimpcolor-2.0.so.0 => /usr/lib/libgimpcolor-2.0.so.0 (0xb7dea000) libgimpbase-2.0.so.0 => /usr/lib/libgimpbase-2.0.so.0 (0xb7ddd000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7b09000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7a8c000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7a71000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7a5a000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7a38000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7a32000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7a04000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7a01000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb79f9000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb79f5000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb79e8000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb79df000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb79db000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb79a6000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb796) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7957000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7897000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb786) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb785d000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb785a000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb77d9000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb76aa000) libgimpmodule-2.0.so.0 => /usr/lib/libgimpmodule-2.0.so.0 (0xb76a6000) /lib/ld-linux.so.2 (0xb7f2) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7683000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7619000) libz.so.1 => /usr/lib/libz.so.1 (0xb7604000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb75e5000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb75c1000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb75be000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb75ba000) Now, if you will notice, this includes: libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7a5a000) Which is the underlying library we are using. Basically, attempting to use the gimp for this is pretty scary and heavy stuff. Deployment on windows becomes far more difficult, and you are asking for a lot of trouble. Not to mention that a delphi app and a gtk+ app are not going to cooperate really well, and its not like you can embed one into the other, there are a lot of event loop concerns with that. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ScanSoft graphic component and The Gimp
On Mon, 2005-10-10 at 19:16 -0400, Kevin Toppenberg wrote: > Hmmm what are you all doing for upload scanning/rotating/manipulation > etc.? > We have (and are) writing code to do it, so you can do all of your basic manipulations from inside our application. We do not have an integrated TWAIN interface, nor are we really planning on having one. There are good usb document scanners available that will scan documents and put them into a folder on your computer in pdf format. Btw, are you planning on supporting pdf? We view that as a huge requirement for our software before shipping our desktop imaging solution to a customer. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ScanSoft graphic component and The Gimp
On Mon, 2005-10-10 at 21:29 -0400, Kevin Toppenberg wrote: > Todd, > > Tell me about why .pdf is important. > Because PDF is the natural choice for text documents, just as TIFF was 10 years ago. > I could attach any file I want to a note. The issue will be the > generation of thumbnails, and also the display of the .pdf documents. > Yup, that is the issue. Currently for our solution, I believe we will be generating a thumbnail image of the first page for the thumbnail, and then showing the entire pdf when it is opened. > Are you going to host the .pdf viewer in your application? It seems > that would also make deployment more difficult. > Somewhat kinda, we are in a unique situation, but we have a library that we are planning on using and distributing to allow pdf viewing. But no, we wont be using adobe's stuff, and it shouldn't add any real issues for deployment for us. > Why would this be better to do than just having a graphic image of the > document? > Because there are good odds that PDF attachments are going to be very common. Right now, e-fax (which gives faxes as PDFs) and pdf scanners are very common, and will become more so. We will still support multipage TIFFs for compatibilities sake, but I would assume we will be recommending PDF over multipage TIFFs. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ScanSoft graphic component and The Gimp
On Tue, 2005-10-11 at 21:37 -0400, Kevin Toppenberg wrote: > OK, Let's say I am willing to support .pdf files. > > Anyone have ideas about how to go about this: > -- OLE adobe's reader? > -- Determine what Todd's mystery library is (gtk+?) libpoppler. Again, not a viable option for a Delphi/Win32 application :( > -- send all media to an imbedded internet explorer (and let it handle > the various file types, including .pdf)? > Id almost suggest this, but then you get screwed for pngs (transparency), also its way way heavy :(. So I'd say the first I guess. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] ScanSoft graphic component and The Gimp
On Tue, 2005-10-11 at 21:16 -0500, Mark Dalton wrote: > > Isn't the goal to move to portability? In other words away > from Delphi? That is one of the problems with CPRS already. > Speaking from experience, reimplementing CPRS is not for the faint of heart, and honestly, is not going to be successfully completed as a totally 100% community driven (meaning no fulltime payed developers) opensource project. Medsphere is hoping to release its crossplatform, portable CPRS replacement/enhancement under some license that will ease the use of it, (I believe, and please, don't quote me on this, because I am not sure, and this stuff changes rapidly that the client itself would be released under a non-OSI compat Non-Commercial license, with the definition of "Commercial" being very liberal (potentially allowing a fair amount of actually commercial reuse), and the GPL for the middleware piece that allows you to write software that uses SOAP to talk to VistA) and move to a completely open development model, that will allow people to 'scratch their own itch', and help drive the development goals and objectives. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 12:30 -0500, Mark Dalton wrote: > > CPRS would take too long for me alone to do in my spare time. (rarely > available) :) > Also I don't have/use Delphi, which is not standard in the HPC world > but then neither > is Java (yet). > > I was curious how much it would cost to have a company convert CPRS to > Java for us. It would be a 'off-shore' > > Since there are about 300 .pas files and more than 200 delphi forms, > they > estimated: > > Approximately, it requires about 6 months to complete the > transition. By applying our minimal rate, $20/hour, it will > cost: $20.400 = 6 months * 170 hours * $20 > > Or on a relaxed schedule to complete in 8-9 months they estimate > $18K. > That is brutally optimistic. If I attempt to get the number of lines in just the .pas files (I know, relatively meaningless, but in all a generally good metric for how unbelievably huge this app really is), I get the following: [EMAIL PROTECTED] find . -name '*.pas' | xargs cat | wc -l 188574 And a sloccount returns: Total Physical Source Lines of Code (SLOC)= 165,989 Development Effort Estimate, Person-Years (Person-Months) = 42.87 (514.39) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 2.23 (26.81) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 19.19 Total Estimated Cost to Develop = $ 5,790,618 (average salary = $56,286/year, overhead = 2.40). Now, I dont know that I put a ton of faith into sloccount's numbers other than the physical source lines (which is accurate, doesnt include whitespace, and comments, etc). Without any regard to the sheer size of this application, porting it is basically an exercise in insanity. I am well aware of this, because at work, this is what we are doing, and we have been doing it for about the last 8 or so months. We are nearing a relative completion point with cprs functionality (some gaps we will not be filling immediately include some of the options dialog, etc), however, it has not been an easy task. Just getting a VistA environment setup that can *test* CPRS is not trivial, and to get actually useful testing with multiple user types, many different patients (as different pieces of the patient information cause CPRS to behave wildly different, like, inpatient or outpatient, or plenty of other things) is absolutely difficult. My experience has been generally one of "Holy crap, CPRS does what?!" I would expect some horribly nasty cost overruns on a project that involved tasking (what seems to be) 4 Indian developers with 6 months to work with a task something that a larger team at the VA (that has easier access to testing, and QA facilities) has been working on for 10+ years. So yeah, I'd say not for the faint of heart. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 12:34 -0700, Greg Woodhouse wrote: > > --- Todd Berman <[EMAIL PROTECTED]> wrote: > >with a task something that a larger team at the VA (that has > > easier > > access to testing, and QA facilities) has been working on for 10+ > > years. > > > > That can be deceptive, too. It hasn't been one big 10 year release > cycle. But I agree with you that trying to do it on a shoestring in 6 > months isn't remotely realistic. Absolutely. But to this day, some semi-major patches are going in, for example, the RPC broker change, while something that we fixed here in an hour or so, would be something I would consider a major and breaking change just due to the code that was affected. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 12:37 -0700, Greg Woodhouse wrote: > > --- Todd Berman <[EMAIL PROTECTED]> wrote: > > > > > So yeah, I'd say not for the faint of heart. > > > > --Todd > > > > I might add that developing a NEW product could prove to be easier, and > a more successful strategy than trying to port the old one. It's like > trying to "program" a neural net weight by weight, when it would be so > much easier to train it again from fresh data. > I would disagree. Developing a 'NEW' product that has the features of CPRS is in effect, porting CPRS regardless of how you want to term it, or change how the GUI works. I don't believe the analogy of neural networks applies in the least in this case. And the only real way to look at this is you have to first understand 160,000 lines of code, and then rewrite them. Sure, you can do this as you go, and sure, you can make tons of changes to make the code smaller and more maintainable (this is something we do all the time), but you still are porting the application and there is no two ways about it. As far as developing an application that functions *actually* different than CPRS, that is in fact MORE work, as you will have to write RPC calls to return the information your application needs that CPRS does not. And then you get into not only being able to write M, but also understanding of tons of various packages in VistA, and this is *NOT* trivial as many of you understand. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 13:20 -0700, Greg Woodhouse wrote: > > --- Todd Berman <[EMAIL PROTECTED]> wrote: > > > On Thu, 2005-10-13 at 12:37 -0700, Greg Woodhouse wrote: > > > > > > --- Todd Berman <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > So yeah, I'd say not for the faint of heart. > > > > > > > > --Todd > > > > > > And the only real way to > > look at this is you have to first understand 160,000 lines of code, > > and > > then rewrite them. > > if you're working from a set of functional requirements, then it is not > necessary to understand the existing code, only what it does. Trying to > "translate" someone else's code can easily be more daunting than > sitting down and writing code to do the same thing. > Greg. If you can understand what code does without understanding that code, let me be the first to congratulate you and offer you a job. That is an amazing skill, that I never believed I would live to see. Seriously though, did you mean something different, or am I confused? > > Sure, you can do this as you go, > > You have to. > > > and sure, you can > > make tons of changes to make the code smaller and more maintainable > > (this is something we do all the time), but you still are porting the > > application and there is no two ways about it. > > Okay, let's suppose I'm given the task of writing a O(n*log n) sorting > algorithm in the "Snowball" programming language. I can sit down and > develop an algorithm from scratch, maybe remember quicksort or merge > sort from a college course, or I can pick up a copy of Knuth, and > convert the sample code to "Snowball". In the fist case (or even the > second) I may come up with code that implements basically the same > algorithm, but can I honestly be said to be porting the code published > in Knuth? I don't think so. I would believe that the implementation of an algorithm and a large functional program are more unlike than alike, but either way, I do understand your point. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 15:50 -0500, Mark Dalton wrote: > > I was not meaning for it to be a big discussion, just curious if it > would be a good path to take. > > I was hoping to find a simple solution and to help make development > quicker and easier > for us to work on it and have it truely portable (versus via wine). > > I guess I will look more at FixIT since that is in a portable language > and perhaps look at > the other peices. I will not suggest porting again :) I just look > for another piece of vista to > work on.. I highly suggest new work be done with portability and > long-term support in mind. > Mark, Just as a bit of extra information, the company I work for, Medsphere, is currently porting CPRS to a new language and toolkit, and it runs (we test every day) on win32, and linux without any issues. It is nearing an initial level of completion of CPRS functionality. We are hoping to make it available under open licensing and with a completely transparent development model, but the main stumbling block right now is the lack of a place to handle our development openly (think sourceforge, and for us sourceforge will not work). And we are unwilling to just do random unsupported code drops, we want to have an open project, one that others can work on. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
Ruben, I will reply to both emails here. So here is the bits from the first that I am replying to: What kind of thing would that be? Just stuff like parts of the templating engine for example, there are a lot of interesting behaviours that you MUST replicate in order to maintain compat. And being compatible is *VERY* important. It alway a mistake to try to duplicate another program becuase your shooting at a moving target and trying to repeat all the mistakes as well as the successes and failures. CPRS is barely moving, its not an issue. And we are not doing a line by line port, but maintaining functional equivalence. The idea is that if you are going to click something in CPRS, and a dialog box comes up that says "You must do x and y", we would do the same (this is just a theoretical example, not something based in the product). To try to say that it would be a mistake to have this functional equivalence is naive, and not something I am willing to discuss, we are doing what makes sense for us atthis stage, and in the future we will be adding new functionality as both we, and the community needs/creates it. As I understand it, CPRS is a delphi program? If so, it will need to be eventually replaced with something less proprietary if Vista is to survive. But it is a mistake to try to duplicate CPRS. Draw new specs and create the programming needed and not in Java (from the pan into the fire? ) but GTK or something similar. Yes. CPRS is a delphi application. It is not a mistake to duplicate CPRS. CPRS has amazing functionality, and studies regularly show it to be a very complete product. We arent using java, but that statement alone shows your ignorance of the entire area, you can write Java programs that use gtk+. If you have followed any of my previous discussions with Kevin, we *ARE* using gtk+, but using gtk+ has nothing to do with the language that you end up using. On Thu, 2005-10-13 at 18:06 -0400, Ruben Safir wrote: > > > > We are hoping to make it available under open licensing and with a > > completely transparent development model, but the main stumbling block > > right now is the lack of a place to handle our development openly (think > > sourceforge, and for us sourceforge will not work). And we are unwilling > > to just do random unsupported code drops, we want to have an open > > project, one that others can work on. > > > > > What is it exactly that you guys need? A webapp that will allow bug tracking (that doesnt suck, and sourceforge.net's issue tracking is horrific), file releases, code browsing, mailing lists / forums (meaning a forum that will also send and receive email), integrated Wiki. In addition to those requirements, some things that would be nice are developer blogs, a project blog and blog aggregator. This is not something that exists. Currently we use SourceForge Enterprise, but we can not open that up due to licensing issues. I am currently attempting to figure out it we can work something out with them to allow it, but as of today, nothing has really been tried. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 18:16 -0400, K.S. Bhaskar wrote: > On Thu, 2005-10-13 at 17:01 -0500, Todd Berman wrote: > > [KSB] <...snip...> > > > We are hoping to make it available under open licensing and with a > > completely transparent development model, but the main stumbling > > block > > right now is the lack of a place to handle our development openly > > (think > > sourceforge, and for us sourceforge will not work). And we are > > unwilling > > to just do random unsupported code drops, we want to have an open > > project, one that others can work on. > > Todd, I'm just curious - why won't Source Forge work for Medsphere? > Also, how about collab.net? > The reasons SF wont work are clear in a previous email, plus, we dont use CVS or SVN for source control, we are using bazaar (a tla derivative that works well, and is amazing to deal with). We do have (currently) a r/o SVN mirror, but it would be nice to see something integrated. I have not looked at collab.net, but I have heard nothing but issues from some of the OOo people. It might be worth a look though. Thanks --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 19:20 -0400, Ruben Safir wrote: > > If you have followed any of my previous discussions with Kevin, we *ARE* > > using gtk+, but using gtk+ has nothing to do with the language that you > > end up using. > > gtk is a toolkit. I've been using it for about 7 years, along with gnome. I > sponsored the Gnome > Developers Sumit not so long ago. I know what gtk is and OBVIOUSLY if I'm > suggesting the use of > gtk instead of JAVA or Delphi then we are talking GTK in a free language > implimentation rather than > the Java AWT. > > Cool! Good to know you were involved with the NYC October Summit, what was it, 2 years ago? Sorry to hear that it was a debacle. And no, it wasn't obviously clear that you meant to use gtk+ instead of Java AWT. I am just going to assume you feel the same about Java Swing. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 19:22 -0400, Ruben Safir wrote: > The stuff ximian uses wouldn't work? I can contact Nat Friedman et al if you > need. > Hahaha. Sorry dude, but name dropping with me doesn't work, if I wanted to talk to Nat or Miguel, I would just pick up my cell and call them. Ximian doesn't HAVE a solution for this, nor does it even exist. The company you are looking for is called Novell. Novell has two tools, one NovellForge, which is basically a rebranded gforge derivate (so no, it wont work) and two, the oft-used combination of bugzilla/mediawiki/mailman. This would possibly work, but it would require a decent amount of time to setup and administrate. And right now, we are more focused on completing the requirements than setting up those tools. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 19:53 -0400, Ruben Safir wrote: > On Thu, Oct 13, 2005 at 04:28:41PM -0700, Todd Berman wrote: > > On Thu, 2005-10-13 at 19:22 -0400, Ruben Safir wrote: > > > The stuff ximian uses wouldn't work? I can contact Nat Friedman et al if > > > you need. > > > > > > > Hahaha. > > > > Sorry dude, but name dropping with me doesn't work, if I wanted to talk > > to Nat or Miguel, I would just pick up my cell and call them. > > > > > Don't be an ass Todd. If you have their tool available to use then it if > its useful for you or not. It has bugzilla and the a web interface that > helps track > things. > What tool is 'their tool'? Bugzilla is a web interface, so I dont understand what 'has bugzilla and the a web interface' means. > Or just continue to complain about it. I was just looking to see if I can > provide you > with something useful to help. Your a big enough ass though, that I doubt I > could actually > be of help. I have never once complained Ruben, if you think that, you are sorely mistaken. I am just giving the explanation as to why have not opened this development process up. Personally, I would love to see it open, but my first responsibility is to see it complete, as I explained. Ruben, I do have plenty of background to understand, if you look around a bit, instead of me just talking on mailing lists about gtk+ and java, I actually maintain and contribute to many large (and small) gtk applications. Either way, you will feel how you feel, and that is how it is, we both have better things to do. Well. I know I certainly do. Sorry that I forgot my rule about continuing conversations with you. I will do better in the future not to. But its good to know that someone who has spent prolly a hundred hours attempting to get a crossplatform CPRS available for use for anyone allowing both new development in a modern language, and linux desktop deployments of VistA is an 'ass'. If that is the prevailing feeling, well, trust me, I am not at a lack of things to spend my time on, and have no issue letting this drop off the relevant people @ medsphere's radar, and onto the floor. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 20:09 -0400, Michael D. Weisner wrote: > Could we put the weapons down, please? > Awww! :) Yes. > I would appreciate it if you would expand on your reasoning for the > selection of a particular product or library rather than just spar with each > other. There is much to be learned from an appropriate exchange of ideas. Actually, the Irony hereis we are already doing exactly what Ruben wants, its not Java and it uses gtk+ > I have no clue as to the difference between Java AWT and Java Swing, for > instance. AWT was the original Java GUI toolkit (Abstract Windowing Toolkit). It was roundly rejected basically. Swing was their 2nd attempt at a gui toolkit, it builds ontop of AWT, but includes a ton of new code and APIs. It has been far more successful, and it with SWT (The IBM Java GUI Toolkit that Eclipse uses) have become really the only two Java toolkits in main use. There are wrappers to other toolkits available in Java, but generally people using Java go towards SWING or AWT without fail. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Cost to convert CPRS to Java
On Thu, 2005-10-13 at 20:17 -0400, Ruben Safir wrote: > > > > What tool is 'their tool'? Bugzilla is a web interface, so I dont > > understand what 'has bugzilla and the a web interface' means. > > > > > Call Nat on your cell and ask him. Bugzilla messages end up on a web > site where they tract the bugs and keep track of them. That is all I > know of it. > > I've never used it. I always hated the thing. OH! You mean Bug-Buddy (I believe), the bug reporting tool of the future, written by one Jacob Berkman (one of my personal heroes). It takes crashes from an application and submits them upstream to the relevant bugzilla installation. Yes, it is useful. However, it isn't useful to us. #1) It only works on linux. #2) It only works on linux on gnome (not that I would recommend anything else). #3) It requires a setup bugzilla installation. We don't have one, and we aren't sure that we will. The issue is not GETTING the buginformation to bugzilla, it is setting up and maintaining an installation of bugzilla, mailman, and mediawiki. It just takes time is all. Time that we are spending in other places right now. I am trying to find time to spend in that place so we can open up the development, but it just isn't there today. If someone in this community was willing to step forward, and offer to setup, and maintain all of these services for the longer term future, then we could look at it more now, but I don't see that happening. Not to mention that we would still have to discuss the entire thing internally and make sure this is something we are comfortable with (this being the holy trinity of bugzilla/mediawiki/mailman). As far as being an ass, I don't believe that I was being one, and I don't believe I was being hostile, I was merely informing you that I am good friends with both Nat and Miguel, and have no need for someone to speak with them on my behalf, and that they also don't have this mythical tool that you seemed to be describing. Again, no intention of being hostile, and I am not sure why you took it that way. Either way, it is irrelevant. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[Hardhats-members] Open Development Software WAS: Cost to convert CPRS to Java
On Thu, 2005-10-13 at 20:46 -0400, Ruben Safir wrote: > > > > It just takes time is all. Time that we are spending in other places > > right now. I am trying to find time to spend in that place so we can > > open up the development, but it just isn't there today. > > > > If someone in this community was willing to step forward, and offer to > > setup, and maintain all of these services for the longer term future, > > then we could look at it more now, but I don't see that happening. Not > > to mention that we would still have to discuss the entire thing > > internally and make sure this is something we are comfortable with (this > > being the holy trinity of bugzilla/mediawiki/mailman). > > > > > I might be able to support that if you think it can be useful. I need > to ask some of the NYLXS people if they want to do this. I would say maybe begin to gather info. We see it as there are a cpl solutions 1) Get VA Software to let us use SFEE for this (our current solution, not perfect, but it does work pretty well already, this is potentially the most minimal amount of work). 2) Setup and maintain bugzilla/mediawiki/mailman. This is possible, however some people at the company *cough*Ben*cough* have issues with how bugzilla looks :). 3) Write and develop our own solution. As insane as this seems, this seems to be the currently preferred avenue. There has been some work on this by some other people, and they seem to have made some decent progress, but not something that will be usable in the near term (near meaning this month or next). 4) Setup a Mambo(or Joomla)/GForge site. This is possible, Personally I would prefer the b/m/m combo to this. (but that is due to familiarity) --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Cost to convert CPRS to Java
On Fri, 2005-10-14 at 00:21 -0400, David Sommers wrote: > MONO IS AN OPTION. (read more...) David, I am happy to inform you that you have won a cookie. Chocolate chip or pecan, your choice :). (And yes, it is not only an option, it is the stark beautiful reality) (And it runs amazingly well). --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Cost to convert CPRS to Java
On Fri, 2005-10-14 at 01:08 -0400, Ruben Safir wrote: > On Fri, 2005-10-14 at 00:21 -0400, David Sommers wrote: > > MONO IS AN OPTION. (read more...) > > > > Is David Sugar will working with Mono? I've been trying to track him > down for months. > A quick grep through the mono and mcs ChangeLogs dont show any David Sugar at all, but I don't know of him, or in what capacity he did mono work. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Open Development Software WAS: Cost to convert CPRS to Java
On Fri, 2005-10-14 at 01:24 -0400, Ruben Safir wrote: > On Thu, 2005-10-13 at 18:04 -0700, Todd Berman wrote: > > On Thu, 2005-10-13 at 20:46 -0400, Ruben Safir wrote: > > > > > > > > It just takes time is all. Time that we are spending in other places > > > > right now. I am trying to find time to spend in that place so we can > > > > open up the development, but it just isn't there today. > > > > > > > > If someone in this community was willing to step forward, and offer to > > > > setup, and maintain all of these services for the longer term future, > > > > then we could look at it more now, but I don't see that happening. Not > > > > to mention that we would still have to discuss the entire thing > > > > internally and make sure this is something we are comfortable with (this > > > > being the holy trinity of bugzilla/mediawiki/mailman). > > > > > > > > > > > > > I might be able to support that if you think it can be useful. I need > > > to ask some of the NYLXS people if they want to do this. > > > > I would say maybe begin to gather info. > > > > We see it as there are a cpl solutions > > > > 1) Get VA Software to let us use SFEE for this (our current solution, > > not perfect, but it does work pretty well already, this is potentially > > the most minimal amount of work). > > > I must be behind the curve on something here. If Larry is the CEO of > Medishere then why doesn't he just donate a Sorceforge enterprise with > code to you? > Because we haven't asked? We are exploring all the available options. Also, please keep in mind that Larry is not some kind of ruling monarch at VA, sure, he has more influence there than you or I, but that doesn't assure anything. As well, believe it or not, we would like to use something opensource to manage and develop an opensource application. Either way, all involved would like option #1 to be the last ditch option, not the first avenue of pursuit. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Cost to convert CPRS to Java
On Fri, 2005-10-14 at 01:30 -0400, Ruben Safir wrote: > David was the head of Bayonne and was working with dotgnu and did a lot > of unrelated work with C++ libs and Object or Common C. He's a FSF > speaker and lives/lived near Morris NJ. I lost touch with him about a > year ago. I think I got a message that his family was moving to > Maryland. > Ah, so dotgnu and mono are not the same project, at all. Not related in any substantive way either, there was a very very limited bit of code sharing from dotgnu to mono about 2.5 or 3 years ago, and dotgnu ships a lot of mono libraries (because mono has actual complete implementations of these libraries and dotgnu does not), but other than that, the projects are not affiliated. Objectively, dotgnu is in its last throes of death, and basically irrelevant, where as mono is a thriving project, moving forward more rapidly than ever. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Cost to convert CPRS to Java
On Fri, 2005-10-14 at 02:11 -0400, Ruben Safir wrote: > Who is working on the Pharmacy Benefits management stuff? > Does this have anything to do with Converting CPRS to Java, or creating a crossplatform client at all? If not, why is it not its own thread with its own subject, and without inline quotes of the other thread? --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] new Java client for VistA.
On Fri, 2005-10-21 at 13:51 -0700, Richard Schilling wrote: > Nancy Anthracite wrote: > > You mentioned the Broker documentation, and I know you are not referring to > > this particular documentation, but I was poking around the Broker > > components > > while attempting to use Delphi a few months back and the Help files with > > them > > were really wonderful. It was like a friend was right there trying to help > > me out and was doing a bang up job of it. > > From the end user standpoint and delphi developer standpoint it's > great. No question. But I haven't seen any documentation yet on the > actual protocol used on the wire yet. Have you run across this? > Honestly, Ive never seen a simpler protocol over the wire. It is pretty painfully easy. The harder issue is to figure out what the data returned is, basically "What does piece 12 of this string do?". But the over the wire stuff is very trivial. I believe I implemented it in about an hour. --Todd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.)
On Sun, 2005-10-23 at 00:36 -0400, Roy Gaber wrote: > Understood. > > What is it that you are looking for? The application data can be had by > looking at the RPC code on both the client and the server. You can view it > using a sniffer as well. Roy, His point is not that he is incapable of figuring it out, nor that it is particularly difficult (I hope, because it really is not). His point is that without documentation, you can't promise that code will always work, there can be subtle (and not so subtle) changes that will break his work. At least, thats how I read the emails, I could be wrong. --Todd --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Linking to VistA - some thoughts
On Sat, 2005-12-03 at 14:16 -0800, Gregory Woodhouse wrote: > On Dec 3, 2005, at 1:54 PM, Kevin Toppenberg wrote: > > > Don't forget to make this language understandable. If this new > > language looks at all like the code you have been showing me, then I > > will have HUGE learning curve. And you might estrange potential > > users. > > > > Kevin > > Trust me, I am most assuredly not happy with my feeble attempts to > explain basic functional concepts in familiar terms. I've got to find > a better way to do it. http://en.wikipedia.org/wiki/Functional_programming explains it pretty well. --Todd --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
