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. :-)
Thanks
Kevin
On 9/5/05, Todd Berman [EMAIL PROTECTED]
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.
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
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
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
Notes below:
On 9/4/05, Todd Berman [EMAIL PROTECTED] wrote:
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
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:
snip
I have then written a RPCBroker call that attempt to pass back the
binary data. I think I am
Todd Berman wrote:
3. Any other thoughts?
Mostly, I would question the need/desire to store this data in VistA,
and access it via the RPC Broker.
These are two separate issues.
If you receive the data in VistA you could store it in MUMPS globals or in the
host file
system. There are pros and
Kevin wrote:
Hmm... I don't know what to think about the security issue. I had a
leak from my office via a standard http server and it was absolutely
horrible. I had committed to not running an http server anywhere near
my patient data. I know that if Apache is set up properly, there
won't be
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
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
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
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.
Kevin
On 9/4/05, Todd Berman [EMAIL PROTECTED] wrote:
On Sun, 2005-09-04 at 21:05 -0400, Ruben Safir wrote:
Anyway.
That is
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
14 matches
Mail list logo
