Richard Schilling wrote:
>> Very interesting. On the surface this sounds similar to some of Steve Zeck's
>> initial work
>> in making a Perl interface to GT.M. In the first level he defined a Perl
>> module for
>> implementing MUMPS data objects. These data objects represent MUMPS globals
>> and
Okay, thanks.
- Original Message -
From: Todd Berman <[EMAIL PROTECTED]>
Date: Sunday, October 23, 2005 6:56 am
Subject: 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:
>
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 fi
Sent: Saturday, October 22, 2005 8:15 PM
To: hardhats-members@lists.sourceforge.net
Subject: RCP Broker Message Structure (was Re: [Hardhats-members] new Java
client for VistA.)
Roy Gaber wrote:
> TCP
I'm not talking about the networking protocol. I'm talking about the
data protoco
Richard Schilling
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard
Schilling
Sent: Friday, October 21, 2005 4:51 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] new Java client for VistA.
Nancy Anthracite wrote:
TCP
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard
Schilling
Sent: Friday, October 21, 2005 4:51 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] new Java client for VistA.
Nancy Anthracite wrote:
> You mentioned
I agree - it's very simple. The first thing I did was sniff the RPC
protocol on the network. I did that a few years ago.
But the problem is that without the protocol properly documented by the
RPC Broker team I can't make any assumptions at all that what I'm seeing
come across the network in
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 mont
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 fr
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 tryi
Very interesting. On the surface this sounds similar to some of Steve Zeck's
initial work
in making a Perl interface to GT.M. In the first level he defined a Perl module
for
implementing MUMPS data objects. These data objects represent MUMPS globals and
have
methods corresponding to all of the
Richard Schilling wrote:
>With the recent discussion on writing Java clients, I thought I would
>mention that in the upcomming release of OpenEMed (www.openemed.net),
>written completely in Java, we'll be releasing a client for GT.M. This
>makes OpenEMed a client of the GT.M platform. And of cour
Very interesting!
On Oct 19, 2005, at 3:55 PM, Richard Schilling wrote:
With the recent discussion on writing Java clients, I thought I
would mention that in the upcomming release of OpenEMed
(www.openemed.net), written completely in Java, we'll be releasing
a client for GT.M. This makes
With the recent discussion on writing Java clients, I thought I would
mention that in the upcomming release of OpenEMed (www.openemed.net),
written completely in Java, we'll be releasing a client for GT.M. This
makes OpenEMed a client of the GT.M platform. And of course, our next
step after t
14 matches
Mail list logo
