Jim Self wrote:
Troy Caldwell wrote:
I have been working on a toolbox of java bridge components that I'm
calling m2java (i know, not very original). As part of this effort I
looked at the "java" files included in the VistAWeb sources, in
particular the MDO package. I'm not sure, but I think this code is
written in some sort of a Microsoft contamination of Java. Anyhow, with
a little effort I was able to rework most of the protocol code to be
Java compliant. I haven't had a chance to test it out yet, but I will
release it shortly on sourceforge.
This sounds very promising.
I'm now waiting for sourceforge approval. I think they are in the middle
of a site update which could be delaying their approval process.
Following is a summary of the components I've put together:
rpcbrokerj - a repackaging of the VistAWeb rpc broker client as a
standalone pure java component.
Is this something that would be suitable for access as a java applet in Mozilla
Firefox?
If so, do you see this giving significant performance or other benefits over an
HTTP based
client if an HTTP version of the broker server were available?
I don't know. I see this as a means for a java program to "speak" the
rpcbroker protocol with a VistA server allowing a wide range of java
based configurations, applet client, JSP web frontend, webstart client,
etc.. All I've done is rework the pseudo-java code in the VistAWeb FOIA
to make it real java, although from what I'm hearing of VistALink, this
may just be duplicated effort.
mj - m parser written in java. Very primitive, doesn't use a proper
grammer and generator such as javacc, but it is simple and can be used
for building code analysis graphs.
Where is this going? MUMPS editor, syntax checking, limited client-side
interpretation of
input transforms?
I seem to recall that there was an announcement some time back of a java based
MUMPS
interpreter, I think on comp.lang.mumps, but I didn't follow up to get details
and I don't
know its status now. I goodled for it now and couldn't find it.
I've heard something as well of an M interpreter implemented in Java,
but have not seen it available. That could definitely open up some
interesting possibilities.
My main motiviation for putting the parser together was for grokking the
20,000 source files in OpenVista and as a nice way to learn M :-) If
this could be used as a basis for some other efforts that would be great.
gnpj - Java port of the GT.M GNP protocol which can be used for
accessing GT.M globals from java (over TCP sockets).
sshscraper - XML based screen scraping state machine that uses Mindterm
SSH. This includes scripts, based on Mark Street's installation
instructions, for installing and configuring OpenVistA. The
variabilities are supplied through properties files and can be driven by
ANT scripts.
filemanj - java wrappers for fileman meta-data elements.
This could be very interesting. Could you give examples of what you have in
mind?
I have done some work in translating fileman metadata to Javascript that is
accessible via
M2Web. I understand that the Javascript literal data format is remarkably
similar to that
of Python and several other dynamic languages and so might be used as a highly
efficient
means of porting data and metadata objects.
That sounds very interesting.
Once again, my efforts originated from a desire to better understand
VistA/M from a java perspective and explore means on interoperation. My
thoughts are directed toward providing meta-data translation and another
integration point. Could data models in Fileman be used as an input for
MDA program generators? Programs for viewing, managing,
manipulating,translating, etc? Is it possible or even useful to create a
Java fileman api that uses reflection on these wrappers?
It seems to me there could be some promise here and perhaps similar
efforts are already underway, thus I'm putting out this set of tools.
-Troy
Any thoughts or feedback would be greatly appreciated.
Troy Caldwell
Buena Vista Solutions Inc.
http://www.buenavistasolutions.com
Kevin Toppenberg wrote:
It may not be documented, but it isn't secret is it?
Can't one just look at the Delphi/pascal code and then
write equivalent code for Java?
Labor intensive I'm sure, but you wouldn't to be quite
as low level as true reverse engineering.
But then again, if the VA already has some first steps
with a web access, doesn't that mean that a java tool
already exists?
Kevin
---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
