Jim Self wrote:
<snip>
While many are approaching the development of new clients (and CPRS
alternatives) from the standpoint of developing a concrete frontend, I'm
focusing my efforts on providing a set of components that address
interoperability between platforms. In the case of VistA, it's
important that the data from VistA get "served up" onto the network
right along side the SQL servers, persistent object stores, and .NET
data sources. Solving interoperability issues addresses this need.
From there it's the question of developing an alternative to CPRS is
more a matter of designing the user interface that calls upon a number
of sources, VistA being one of them.
Food for thought ....
That is also part of it. All requests for a given M2Web server go through a
common entry
point that provides a uniform base platform for web applications (usually MUMPS
based).
The most basic framework provides a definition of web resources (URI's) with
access
characteristics and login sessions tied to a MUMPS database, such as the VistA
User file
(#200).
Dave Forslund has been doing something somewhat similar with OpenEMed,
but his work is going a step further than this and tackling the question
of interoperability through the use of CORBA and implementing the
CORBAMED specificaiton. I know ESI objects has already done some of
this work by implementing a CORBA server, but they haven't addressed
CORBAMED yet.
I may have time to implement CORBAMED components on GT.M eventually ....
<snip>
The technology of the web, especially Mozilla Firefox, is constantly being
improved - so
much so that I doubt that anyone can keep up with it. If you are not working
with it (ha -
even if you are ;) then there are undoubtedly large areas of functionality of
which you
are only vaguely aware.
I worry more about the question of data delivery to the architecture's
endpoint (e.g. providing data through a JSP, server side includes, ASP,
etc...). The browser used, ideally shouldn't be an issue at all and the
data sent to the client is be in some form of a Lowest Common
Demoninator (plain old HTML, XML, JSP, etc...).
With that in mind, the troubles I've seen are related directly to
interoperability.
I liked Swing but gave up on it some time back when we found that Swing based
applets were
essentially unusable. That may well have changed by now, but I have largely
ignored most
XML or Java based development in recent years because it doesn't seem to offer
sufficient
necessary functionality beyond Mozilla to compensate for the additional
complexity and
learning curve it would bring to our development environment.
Swing is pretty good now ..... most of the problems you speak of have
been resolved, and I think for the most part at the time there were more
issues in JVM implementation and how the web browsers managed Java
applets than anything.
Richard Schilling
Cognition Group, Inc.
-------------------------------------------------------
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
