ClearHealth project compiles VistA to MUMPS-LESS web interface.
Fred Trotter
version of VistA working without MUMPS.
Apparently the strategy is to compile the MUMPS code to C, run it
through some extensive processing, and then it becomes available in a
fashion that can be called from php.
They are currently in beta in one hospital with this technology.
I know very little about it so I cannot field questions. For those who
are very interested, take a look at this post on the ClearHealth
forums:
http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
I am sure they might field questions from you on that same forum.
Interesting times :)
-FT
--
Fred Trotter
http://www.fredtrotter.com
Joseph Dal Molin
is simply awe inspiring :-)
J
Joseph Dal Molin
J.
> .
>
Nancy Anthracite
--
Nancy Anthracite
Chris Richardson
Roger A. Maduro
should have the same functionality as CPRS but running on a browser. I
don't any of the MUMPS code is changed.
Roger
rtweed
would want to learn it instead of junking it. A lot of people will be
busy quite happily learning Python right now, simply because Google's
App Engine requires it. Turn a Google or Yahoo onto the wonders of
Mumps and globals and the tide would turn for sure. Will it happen?
Probably not.
In the meantime, all you can do is be safe in the knowledge that most
of these efforts have been ultimately doomed to failure for one reason
or another. The amazing thing is that nobody ever thinks to do any
research into the many high profile casualties there have been over
the years, or consider the untold millions (or is that billions?) that
have been poured down the "replace mumps at any cost" toilet. Why
should their efforts be successful in the light of such grim evidence?
Shrug your shoulders, smile sweetly and give a knowing sigh...
Chris Richardson
That is not what they said. They said " a web-based version of VistA
working without MUMPS" and "the strategy is to compile the MUMPS code to C,
run it through some extensive processing, and then it becomes available in a
fashion that can be called from php." I believe that both GTM and Cache can
work with PHP just fine without having to be converted to "C". I would love
to see their data model and watch their performance stats. I have a pretty
good idea what those will look like. If they wanted to say that they were
just replacing CPRS, then they should say so. If they didn't replace CPRS,
they could still claim that CPRS runs without MUMPS right now (as long as
you don't expect any data to come with it). If I am not mistaken, GT.M is
already written in "C" or some other compiler and pretty well optimized for
the data handling model. Re-inventing MUMPS in C would be a trick, getting
scalability and performance would be a miracle. Say you could (by some
miracle), what would you be loosing? Access to the source code (it is all a
black box and the end user is kept at arms length from verifying the
operation of the code). The user is at the mercy of the vendor once again.
Is this a good thing? I don't think so. Where is the good here?
Interesting, but is it really necessary? What is wrong with MUMPS? I
have heard of such efforts to replace MUMPS for over 20 years. If all of
this effort to replace MUMPS was so easy, it would have been done already.
It isn't a matter of money, the DoD and the VA have spent gobs of money to
replace it. What is keeping them?
Joseph Dal Molin
based medicine and realize that the opportunity cost of chasing the next
software fad in health systems is measured in lives.
Joseph
> .
>
Roger A. Maduro
As I said, I've head some extensive discussions with the Clear Health
guys on this. They took at look at CAV Systems' MJSP
<http://mjsp.sourceforge.net/>. This is an open source toolset that
can be used to create rich HTML clients that can run on top of Mumps
applications. MJSP has been used by CAV Systems to create some
beautiful browser-based web apps for Mumps applications. I have seen
these demoed and seen the CAV guys write HTML code for the base Mumps
app on the fly. It's impressive. CAV Systems' code however (for the
web piece) is J2EE. You can read the sourceforge documentation to get
the details.
ClearHealth has been doing all their browser work using PHP. Thus they
either used the MJSP code that connects to Mumps to connect to the RPC
broker or developed similar code using MJSP as the model (I am still
not clear). Then they used PHP to render the web front end. What the
Clear Health people told me is that they have not touched the Mumps
code, so I don't know where that part comes from.
The idea here is to replace the Delphi code behind CPRS with an
Ajax/Web 2.0 framework.
At this point, I would say that David Uhlman or some of the Clear
Health guys will hopefully provide some more details. I think this is
a very significant development and hope that they continue working on
it.
Roger
st...@stevenowen.com
client as the next generation CPRS. That's why I'm putting together a
developer's virtual machine based on M/gateway's Enterprise Web Developer
platform. Write your methods on the mumps side, compile the php pages on
the mumps side, and output them to your webserver. Plus, it has custom tags
to make use of javascript toolkits like extJS.
Yeah, very cool stuff this web 2.0
Chris Richardson
I'm not at odds at all with rehosting CPRS as a thin client. The
coordination of the clients with the server is a major headache in the
field. The webification of VistA is the logical extension of the
technology, but if you read the statements being made, that was not at all
clear from their words. MUMPS never was to run on the client, but it is
very difficult to run CPRS without VistA and the RPC interface (or weblink
or any of the other technologies being brought forward) on the server.
I can't tell you the number of times I have seen people say, "CPRS is
great, but now if we could just get rid of that darned VistA" without
knowning that the power of the rendition of CPRS or a web interface is still
the VistA-MUMPS back end service. BTW, the idea of running VistA from the
web is not new, Jim Self and his folks at UC Davis have accomplished this
about 15 or more years ago.
Maury Pepper
www.clear-health.com/download/tepr-2008.pdf
One slide contains this summary:
● Web Based CPRS
● Possible Web Based ViewCentric
● Proven System, Excellent Record
● Ease of Web Based Systems,
especially over M stack
● End-to-end system with
scheduling and billing
● Inpatient or ambulatory
Compatible with CH Advantage
● M/CACHE to PHP/MySQL & C,
Modern Technology
● Compatible with HealthCloud
I don't know how to interpret the next to last point which refers to M/CACHE.
Roger mentioned CAV Systems and their Java library. They also have a product (not open source) called JUMPS which will convert MUMPS to Java + SQL. Perhaps ClearHealth has used this or considered using it.
st...@stevenowen.com
C...that seems a bit odd if they can access the mumps backend via MJSP
david...@gmail.com
discussion coming from us directly. I do not in any way want to offer
a general commentary on why some people want to use MUMPS or don't
want to, or X language is better than Y, I am not looking to instigate
a flame war or really say that what we are doing is a better or worse
approach from a technical standpoint than anything else. It is the
right approach for us. Additionally I need to make clear that this is
a preliminary announcement, we have moved beyond proof of concept but
there is still a lot to be done. We now have 2 beta sites we will be
rolling out over the course of the next 12-18 months while actively
seeking 1 or more additional sites.
What we are doing:
*Implementing a CPRS-like web based interface
*Breaking a live VistA server into static libraries and components
that can be utilized outside of a running GT.M instance or at-least a
continuously running instance
*Extracting datasets and so forth tied up in CACHE to be accessible in
other things including MySQL
*Integrating features that based on our market aren't present or are
underrepresented in a VistA/WorldVistA/etc installation with regard to
scheduling and X12 electronic billing.
*Enabling a lot of interfaces and integration points so that both data
and logic, that from our standpoint were difficult to work with in
VistA, are accessible using things like a PHP module and web services.
*The entirety of what we are going will be licensed under a feasible
combination of GPL and LGPL
What we aren't doing:
*Saying the M/Mumps/WorldVistA etc is good, bad or otherwise
*Saying we have a completed production ready system right now
*Saying it is trivial to get from where we are now to a completed
production system
*Building a web based front-end that uses RPC/etc to talk to a VistA
server
With respect to understanding the industry and the history of VistA we
aren't novices here, we are by most measure the largest open source
healthcare solution in patients, sites and dollars in the US. We
understand the engineering challenges. We understand that in the past
people have tried various other strategies and have failed. I am happy
to have fruitful discourse about what we are doing, I am not
interested in having a zealous back and forth about why we should or
shouldn't be doing this. If you disagree with our approach or think we
are crazy for x,y, or z that is absolutely your right and noted for
the record.
With regard to the "doomed to fail" comments, we are not naive and
have been doing complicated difficult things with Open Source with a
combined experience amongst are staff of more than 100 years. People
are welcome to their opinion but I think if you look at the life of
virtually any large open source project today it arose from a
situation where a lot of people said "doomed to fail". Linux, Apache,
MySQL, and PHP as well as many others have all, at times, had that
comment made about them and they now represent the most popular system
for each of their respective markets .
Our analysis of the market indicated that there were a lot of
institutions interested in VistA based solutions that for a variety of
practical reasons had difficulties integrating with the current
architecture, making customizations to the current architecture or
addressing needs in a different way than the current architecture can
reasonably provide for, that is our motivation for doing what we are
doing.
I expect that the first open source licensed code bundle we will be
releasing is still several weeks away. As the discussion indicated
there are a lot of technical challenges to what we are doing and we
want to first release to be reasonably accessible with regard to its
ease in compiling and getting running a basic version of the WebVistA
system. We do have some screenshots and such we will be releasing as
time permits.
I hope this clarify to some extent where we are and I am happy to
response to any inquiries beyond that. Thanks.
-David Uhlman
Customer Happiness Guru & CEO
ClearHealth Inc.
K.S. Bhaskar
you use Kevin O'Kane's MUMPS to C translator to translate VistA to C?
Anything you can say to explain your server side technology would be
appreciated.
Regards
-- Bhaskar
On May 22, 3:27 pm, daviduhl...@gmail.com wrote:
> I wanted to weight in here so that there can be some on-record
> discussion coming from us directly. I do not in any way want to offer
> a general commentary on why some people want to use MUMPS or don't
> want to, or X language is better than Y, I am not looking to instigate
> a flame war or really say that what we are doing is a better or worse
> approach from a technical standpoint than anything else. It is the
> right approach for us. Additionally I need to make clear that this is
> a preliminary announcement, we have moved beyond proof of concept but
> there is still a lot to be done. We now have 2 beta sites we will be
> rolling out over the course of the next 12-18 months while actively
> seeking 1 or more additional sites.
Jim Self
BTW, the idea of running VistA from the web is not new, Jim Self and his folks at UC Davis have accomplished this about 15 or more years ago.
I think we clearly showed *how* it could be done about that long ago with a web interface to our own system (VMACS, for veterinary medicine) and some general tools and demo applications showing some of the possibilities for general M-to-Web applications, including high-level data to table generation in HTML, Javascript, and later XML.
More recent are some tools for generating and processing AJAX data entry forms tied to Fileman API's and data definitions. There is also an initial implementation of a functional menu interface for the VistA Options file.
-- --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Information Technology Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) --------------------------------------- M2Web Demonstration with VistA (http://vista.vmth.ucdavis.edu/) ---------------------------------------
Jim Self
I think they are taking the right approach by developing a rich browser client as the next generation CPRS.
That's why I'm putting together a developer's virtual machine based on M/gateway's Enterprise Web Developer platform. Write your methods on the mumps side, compile the php pages on the mumps side, and output them to your webserver.
What advantages do you see in generating dynamic HTML, Javascript, etc for VistA from php instead of doing it from mumps?
Or might you be doing both? That might be relatively easy with EWD and/or M2Web?
Plus, it has custom tags to make use of javascript toolkits like extJS.
I built some preliminary M2Web tools a while back for generating and processing Dojo based data entry forms for VistA from Fileman data definitions and API's. These can be used to make applications with very little source code.
Unfortunately the version I started with (Dojo 0.43) lacked some of the functionality I would like to see in a full scale data interface and upgrading to the current version (1.1) requires significant re-learning and re-programming. Their data API's and data enabled widgets have changed greatly between versions.
Yeah, very cool stuff this web 2.0
Still there must be some commonality in the different approaches...
If you keep a blog reporting your progress and problems along the way (and/or report it to hardhats) it might help to illuminate the way for you as well as others.
rtweed
> I agree that EWD seems worth investigating. (Sorry, Rob, but I haven't
> gone very far with that yet. When I last tried, there were some issues
> with getting the appliance to load in Parallels on my Mac.)
network driver it uses seems much more reliable
> What advantages do you see in generating dynamic HTML, Javascript, etc
> for VistA from php instead of doing it from mumps?
the actual markup, Javascript etc is being served up from. It
abstracts that away from you so it's largely irrelevant.
The real advantage of EWD is that it makes the task manageable and
scalable. With increasingly complex UI functionality becoming
possible with the latest generations of Javascript-based widgets from
the likes of Yahoo, Dojo, ExtJS etc, the pages you have to serve up
become increasingly complex to write and (critically) to maintain.
That's where EWD's Ajax framework comes in - it simplifies how you
conceptually design your pages, and also where the custom tags come
in, because they can simplify the complex JSON-structured Javascript
coding required for these widgets down to a bunch of simple to use and
simple to understand XML tags. Witness the EWD/ExtJS desktop which
you can get working with just 2 custom tags: see
http://gradvs1.mgateway.com/download/extjs4.0.684.pdf, page 34.
A separate question is whether EWD could be made to work with GT.M
without the need for PHP. The model there would be akin to WebLink
and Cache. That's something I'm currently pondering. However, as
people who use EWD with Cache know, there would be no difference
within your EWD pages: whether and how an EWD application runs with
PHP, CSP, JSP or WebLink is handled by EWD's compiler and makes no
difference to the developer.
>
> Or might you be doing both? That might be relatively easy with EWD
> and/or M2Web?
>
> > Plus, it has custom tags
> > to make use of javascript toolkits like extJS.
>
> Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few
> links from google comparing them but all from before Dojo 1.0.
>
everyone else is now playing catch-up with them. The latest ExtJS
widget library is nothing short of stunning and unbelievably
sophisticated. From what I've seen of the current CPRS interface,
there's not one bit of functionality that couldn't be done using ExtJS
widgets. The problem is that it would involve some very complex use
of the ExtJS widgets, but the good news is that EWD would make it do-
able and maintainable.
I'm afraid that the days of the hacked-together MUMPS routine to
generate web pages are out the window when you're into this level of
UI sophistication. You need a tailor-made toolset to make it
practical, manageable and maintainable and avoid going insane!
> I built some preliminary M2Web tools a while back for generating and
> processing Dojo based data entry forms for VistA from Fileman data
> definitions and API's. These can be used to make applications with very
> little source code.
>
complex, it's that if you attempt to emulate something like the CPRS
interface, you end up with so much stuff to write, manage and
maintain. You need automation tools like EWD to allow you to
conceptually simplify the process and allow you to crank out the
pages. And of course you need to maintain state and security, all
stuff done automatically for you by EWD so that burden is relieved
also.
> Unfortunately the version I started with (Dojo 0.43) lacked some of the
> functionality I would like to see in a full scale data interface and
> upgrading to the current version (1.1) requires significant re-learning
> and re-programming. Their data API's and data enabled widgets have
> changed greatly between versions.
at a blistering pace. One more reason for custom tags: to abstract
the physical implementation so the underlying code can be kept up to
date with the widget libraries whilst their use in your pages can
remain relatively constant.
> Yeah, very cool stuff this web 2.0
>
> I agree. There seem to be many ways to go about developing it. So much
> to learn and so little spare time to do it in...
idea, right?
>
> Still there must be some commonality in the different approaches...
>
> If you keep a blog reporting your progress and problems along the way
> (and/or report it to hardhats) it might help to illuminate the way for
> you as well as others.
and Vista, so I too am looking forward to what he'll be able to
demonstrate in the hopefully not too distant future
Rob
Fred Trotter
Remember that this is completely second hand information.
I have neither seen the code, the process, nor the interface. I am
just parroting what was said in the talk at TEPR and I could easily be
wrong. I think it is pretty relevant that Roger has been talking to
the same people and has a very different technical summary. I would
assume that my 10000 foot summary turns out to be pretty off base. The
only reason I indicated that it was not just a CPRS replacement was
that I understand that David either has the pharmacy stuff working or
believes that he will be able to get it working.
As with anyone who has even a passing familiarlity with
MUMPS, I appropriately dubious. However I have seen David do some
amazing things with PHP, and I while he may sometimes be
overconfident, I have never known him to completely BS. So I am very
interested to see what they have. I just wanted you to know that I do
not actually know what they have... so make sure you do not rely on my
understanding too much.
On Thu, May 22, 2008 at 9:37 AM, Chris Richardson <r...@rcresearch.us> wrote:
>
> Roger;
>
> That is not what they said. They said " a web-based version of VistA
> working without MUMPS" and "the strategy is to compile the MUMPS code to C,
> run it through some extensive processing, and then it becomes available in a
> fashion that can be called from php." I believe that both GTM and Cache can
> work with PHP just fine without having to be converted to "C". I would love
> to see their data model and watch their performance stats. I have a pretty
> good idea what those will look like. If they wanted to say that they were
> just replacing CPRS, then they should say so. If they didn't replace CPRS,
> they could still claim that CPRS runs without MUMPS right now (as long as
> you don't expect any data to come with it). If I am not mistaken, GT.M is
> already written in "C" or some other compiler and pretty well optimized for
> the data handling model. Re-inventing MUMPS in C would be a trick, getting
> scalability and performance would be a miracle. Say you could (by some
> miracle), what would you be loosing? Access to the source code (it is all a
> black box and the end user is kept at arms length from verifying the
> operation of the code). The user is at the mercy of the vendor once again.
> Is this a good thing? I don't think so. Where is the good here?
>
> Interesting, but is it really necessary? What is wrong with MUMPS? I
> have heard of such efforts to replace MUMPS for over 20 years. If all of
> this effort to replace MUMPS was so easy, it would have been done already.
> It isn't a matter of money, the DoD and the VA have spent gobs of money to
> replace it. What is keeping them?
>
>
--
Fred Trotter
http://www.fredtrotter.com
George Timson
writes more MUMPS code and XECUTEs it on the fly. MUMPS really is the
"X language", to use Mr. Uhlman 's term. :-)
FileMan uses XECUTE all over the place. To be able to run a FileMan
report "outside a continuously running instance", how would the XECUTE
command be handled?
--George Timson
Chris Richardson
I am not trying to shoot the messenger, just find out where the reality
ends and the FUD begins. Yes, this is interesting work, and I have seen
many attempts at replacing MUMPS with compiled code on multiple occassions,
but why? Why is there all of this effort to replace one tool which was way
ahead of its time? Does VistA need to be re-writen, sure, but why not use
what we have and what works rather than build a compiled monstrosity that
you may or may not get the source code for. Where is the advantage? Lets
use what works, has worked, and has proven to be scalable beyond many of the
other environments that are being proped up to try to replace it, and only
coming in a poor second in nearly every case. I have seen no other system
out there that can hold and manage more than 30 years of patient history
like VistA can (the major exception is Octo Barnetts' model at Beth Israel
Hospital in Boston, but that is a MUMPS model as well. MUMPS must be doing
something right.
----- Original Message -----
From: "Fred Trotter" <fred.t...@gmail.com>
To: <Hard...@googlegroups.com>
Sent: Friday, May 23, 2008 1:45 PM
Subject: [Hardhats] Re: ClearHealth project compiles VistA to MUMPS-LESS web
interface.
>
Aylesworth, Marc CTR USAF AFMC AFRL/RISE
Marc Aylesworth
RRC C3I Grooup
525 Brooks Road
Rome, NY 13440
PH: 315-330-2422
________________________________
http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
Interesting times :)
-FT
--
Fred Trotter
http://www.fredtrotter.com <http://www.fredtrotter.com/>
Maury Pepper
kdt...@gmail.com
to standard object files, and is callable by php.
It's called GTM.
Kevin
Fred Trotter
Generally that makes it a non-starter.
kdt...@gmail.com
call in from other languages. For example, someone has written an
interface form perl to GTM. So if php 5 is not able to connect to
another program written in c that has predefined channels for such a
connection (such as GTM), then I would see that as a limitation of
php.
I suspect that it is doable, but there just hasn't been a need for it,
so the channel has not yet been created.
Kevin
kdt...@gmail.com
http://www.fidelityinfoservices.com/FNFIS/Markets/NonFinancialIndustries/Healthcare/GTM/Product/TechnologyDetail/
Kevin
kdt...@gmail.com
finish office charts...)
According to this link:
http://www.php.net/manual/en/intro.pdo.php
There would need to be a database driver written for GT.M
This is a list of databases already having a driver established.
The following drivers currently implement the PDO interface:
Driver name Supported databases
PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase
PDO_FIREBIRD Firebird/Interbase 6
PDO_IBM IBM DB2
PDO_INFORMIX IBM Informix Dynamic Server
PDO_MYSQL MySQL 3.x/4.x/5.x
PDO_OCI Oracle Call Interface
PDO_ODBC ODBC v3 (IBM DB2, unixODBC and win32 ODBC)
PDO_PGSQL PostgreSQL
PDO_SQLITE SQLite 3 and SQLite 2
So a connection is theoretically possible, but not currently ready to
go. I would guess that the interface would need to talk SQL, so one
would have to include a GT.M SQL engine as well....
Sigh, it's hard when it seems that 98% of the rest of the world talks
a different language...
rtweed
path=mgwsiMenu) provides a connection between GT.M and:
- PHP (all versions)
- Java Server Pages
- ASP.Net
Our latest version, due for release soon, adds Python and Ruby to the
list.
In all cases MGWSI allows you to access a GT.M system from within any
of these environments, to access and manipulate globals and/or to
invoke routines/functions and send/receive data.
It's free too!
Rob
kdt...@gmail.com
Does it doe the interface via one of the PDO type drivers mentioned in
my prior post? Can you elaborate a bit on the technology? How is it
set up? I don't operate much in PHP etc, so don't know the details.
I guess with this the LAMP stack could be:
L - Linux
A - Apache
M - MUMPS :-)
P - PHP
Kevin
edsalvador
language.
I think it is a matter of Vista gaining traction in the physician
practice community. You can knock the current commercial EMR
applications all you want, however, they have anywhere from hundreds
to thousands of users.
How many does Vista have? What is being done by WorldVista to gain
market share?
When you can solve this issue, the point will be moot.
Ed
On May 21, 10:33 pm, Joseph Dal Molin <dalmo...@e-cology.ca> wrote:
> ....what some people will do to avoid learning a new programing language
> is simply awe inspiring :-)
>
> J
>
>
>
> > Today at TEPR, ClearHealth announced that they have a web-based
> > version of VistA working without MUMPS.
>
> > Apparently the strategy is to compile the MUMPS code to C, run it
> > through some extensive processing, and then it becomes available in a
> > fashion that can be called from php.
>
> > They are currently in beta in one hospital with this technology.
>
> > I know very little about it so I cannot field questions. For those who
> > are very interested, take a look at this post on the ClearHealth
> > forums:
>
> >http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
>
> > I am sure they might field questions from you on that same forum.
>
> > Interesting times :)
>
>
> - Show quoted text -
K.S. Bhaskar
porting a few older PHP modules to PHP 5 is a show-stopping obstacle?
I know people who saw how small http://downloads.sourceforge.net/fis-gtm/phpgtcm.tar.gz
is, read it and then wrote their own Java interface to GT.M.
In any case, you can also use PIP (http://www.fis-pip.com &
http://sourceforge.net/projects/pip) to get FOSS JDBC/SQL access to an
M/Fileman database, but that may be more work.
Also, as Rob points out, the M Gateway code (which is really cool)
provides another great free (don't know if it is Free) way to access M/
Fileman data.
I fully understand if you are stymied by lack of interest - let's not
forget that MUMPS is infectious! 8-)- - lack of funding, lack of
enthusiasm, etc., but you shouldn't be stymied by a lack of
technology.
Regards
-- Bhaskar
K.S. Bhaskar
For the last three months WorldVistA EHR has been downloaded from
Source Forge at the rate of around 1400 downloads/month and last week
was at 98.38 percentile of all projects by activity at Source Forge.
The WorldVistA project (mostly FOIA VistA flavors) was at 96.83
percentile last week and has been averaging around 700 downloads/month
for the last three months.
GT.M (independent of activity and downloads bundled with VistA) was at
98.73 percentile last week, and has been averaging 600 downloads/month
over the last three months.
So, you're probably right - it's a dying application on a technology
that's about to go belly up. Time to move on to something else...
any decade now.
-- Bhaskar
Fred Trotter
to GTM bridge. From what I can tell python has many of the same
web-enabled benefits of php, with stricter OOP.
Again, it is really an issue of what is doable and what I personally
have the bandwidth for.
edsalvador
Download stats are meaningless unless physicians actually use the
application.
Where are the real-world stats?
Ed
I agree that the applications has potential.
However, like someone told me:
Sh*t in one hand and wish in the other. See which one gets filled-up
faster.
rtweed
Developer (EWD) (http://www.mgateway.com/ewd.htm). MGWSI is the key
underlying reason why EWD can potentially cross-compile to PHP or
potentially any other web technology: MGWSI provides a normalised way
of accessing GT.M (or Cache) from them all.
You can use MGWSI manually however if you really want to hand-craft
your PHP, Python or whatever (personally I no longer see the point
doing this any more as EWD automates the whole process and avoids me
having to write any PHP or whatever code).
MGWSI is a general-purpoose service that mediates between two systems,
one deemed to be the server (in this case GT.M) and the other the
client (eg PHP, JSP etc). The endpoints may be on the same or
separate hardware: provided they can communicate via TCP/IP, then
MGWSI will integrate them. One instance of MGWSI can support access
to multiple GT.M and/or Cache servers from a client environment,
allowing it to support distributed back-end data or heterogeneous
database access.
All the documentation for MGWSI is included in the downloadable zip
file from our web site (www.mgateway.com), but here's a few examples
which will perhaps help to explain how you use it.
PHP:
$result = m_proc("myFunc^myRoutine", $ar2, "London");
Invokes a call from within PHP to GT.M, the equivalent of s result=$
$myFunc^myRoutine(.ar2,"London")
where ar2 is an array. Arrays are mapped automatically between PHP's
associative arrays and M's local arrays. GT.M may update the array if
required and send back new content.
Various low-level primitive global calls, eg:
m_set("^MGWCust", 1, "Rob Tweed");
m_set("^MGWCust", 2, "John Smith");
from within PHP would create:
^MGWCust(1)="Rob Tweed"
^MGWCust(2)="John Smith"
Java Server Pages equivalent to the above (ie calls from within JSP
pages):
m_jsp.ma_arg_set_array (args, 1, records, 1); // pass-by-
reference.
m_jsp.ma_arg_set_string(args, 2, "London", 0);
m_jsp.ma_proc("myFunc^myRoutine", args, 2)
key[0] = "1"; // no of subscripts
key[1] = "1"; // value of subscript 1
m_jsp.ma_set("^MGWCust", key, "Rob Tweed");
key[1] = "2";
m_jsp.ma_set("^MGWCust", key, "John Smith");
All the other language interfaces work similarly to either the JSP or
PHP ones. You have functions for:
- setting globals
- killling globals
- traversing globals ($order equivalent)
- merging to/from globals or local arrays
- invoking routines (+ sending/receiving data)
- invoking functions (+ sending/receiving data)
MGWSI is deliberately kept very simple and straightforward, but allows
complete flexibility. The great thing about MGWSI is that it allows
you to invoke legacy functions from within any of the supported web
technologies/languages, making it idea for interfacing with existing
Vista business logic.
If you want to see MGWSI in action, the simplest approach is to
download our EWD Virtual Appliance which includes MGWSI pre-installed
and pre-configured in a VMWare Virtual Machine based on Linux/PHP/
Apache/GT.M. Most of the time in the Virtual Appliance you won't even
be aware it's there, since it's providing the gateway between GT.M and
EWD-generated PHP applications.
You'll also be using MGWSI if you download the Asus Eee kit for EWD
which I described in a recent post here and which Steve Owen has been
using.
For more information,. download MGWSI and consult the documentation.
All our products are free to download and use without restriction and
can be obtained from http://www.mgateway.com
Rob
rtweed
technology I was using when front-ending a GT.M application, provided
it runs fast and scales well.
That's the idea of our Enterprise Web Developer (EWD) technology which
allows you to describe your web applications in a high-level
abstracted way that makes it appear as if you're just designing a
storyboard of web pages with calls to GT.M functions to fetch the data
for each page and validate/save data coming off the page. EWD then
generates the language/web technology of your choice, so if you want
to run your application using PHP, just compile to PHP and EWD writes
all the PHP code for you. Once I've integrated the new MGWSI build
that supports Python, you'll be able to select Python as the
compilation target and EWD will generate Python code instead from the
original application: the application will run identically in either
PHP or Python without you making any changes to the EWD application
definition.
I have versions of demo applications written using EWD that will run,
simultaneously if required, in any or all of PHP, VB.Net and JSP all
against the same back-end GT.M database.
When you have technology that allows you to do that, it really is
pretty much irrelevant whether you choose Python or PHP. Since all
the PHP, Python, JSP etc code is 100% generated, whether the target
language is an OO one or not is neither here nor there. All you need
to focus on is the page/UI design and the back-end function calls you
need to make to access the back-end GT.M functions which fetch and
update your database. Want to see how/if your application would
perform and scale better in a PHP, Python or JSP environment? Just
recompile and give it a go: it really is as simple as that once you're
writing apps using EWD.
Available bandwidth is what it's all about, as you say. Making you
more productive is what EWD is all about, and avoiding having to grub
around at the low level in PHP, JSP, Python or whatever code is one of
the keys to achieving that productivity.
Rob
K.S. Bhaskar
are starting VistA implementations. I don't disagree with you that
the installed base is small (unless you count the dozens of secondary
and tertiary care hospitals where VistA is implemented at Instituto
Mexicano del Seguro Social). But the number of new implementation
projects seems large, and growing, as evidenced, for example by
attendance at VistA Community Meetings.
Regards
-- Bhaskar
Fred Trotter
This is, in my view, exactly what is needed for php <-> GTM
integration and could be a real game-changer. However there is a
licensing issue. I see no sourcecode download from your site, and I
see no mention of a specific license. I am also unsure of how you can
create a php module that links into GTM without complying with the GPL
license that GTM (linux version) comes with.
What is the license of your code. Would you consider releasing it under the GPL?
rtweed
considering going down that route.
We don't release source code for the core MGWSI service component.
The GT.M-side listener/daemon code is provided as source code however,
so I see no conflict with GT.M licensing in that respect.
Our licensing is very liberal. We allow you to use EWD and MGWSI
freely to whatever extent you like, and you can redistribute it as you
wish. The only limitation is that our products are provided without
support.
MGWSI is now the standard PHP integration gateway in the Cache
community and is in use by a large number of users, and it would be
good to see similar uptake in the GT.M community.
K.S. Bhaskar
The PHP client talks over a TCP connection to a GT.CM server process
that is part of GT.M. None of GPL v2, GPL v3 or AGPL v3 have any
clause that causes any license interaction between a client and a
server that are on two sides of a TCP connection.
From a 2003 forum post by some guy called Bhaskar:
"Should you wish to use GT.M as a database engine, please be assured
that Sanchez does not place any restriction on the licensing or
publication of source code for applications developed using GT.M. I
have clarified this previously in comp.lang.mumps and other forums.
If, on the other hand, you make changes to GT.M itself and distribute
the modified version of GT.M, I would expect you to make source code
for your changes available under the terms of the GPL."
From GPL v3 and AGPL v3:
"A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate."
There is no interaction between the licensing of application code that
runs on GT.M with the FOSS licensing used for GT.M itself.
Regards
-- Bhaskar
Fred Trotter
>
> Our licensing is not currently Open Source, though we are actively
> considering going down that route.
>
>
It seems like going open source is a pretty obvious choice for you.
The "GTM community" are attracted to GTM because of its license. Using
GTM, GNU/Linux and either WorldVistA or, now Medsphere OpenVistA, we
can have a complete FOSS stack. There is no way that we would consider
working with a project that messes that up. So if you are actually
interested in serious adoption by that part of the VistA commuity, it
will not happen without a license change.
This is true for many software companies, including Intersystems and
DSS. The difference is that I do not see how you are making any money
from your software. You are already doing a services model, so I do
not see how you would be impacted by this negatively at all.
If you release your code you stand to become a central component in
the "webifcation of VistA" effort. As the ClearHealth efforts
demonstrate, that is going to happen one way or another. The only
question is with what particular solution?
There is also no reason that you would need to open source everything.
You could keep your cache module proprietary. GTM actually does this
with its non-Linux binaries, (or it used to) and that is totally
legit.
Fred Trotter
Actually the AGPL v3 is designed to close this "ASP
Loophole" but I know that you are still using the GPL.
I just did not understand what architecture they were
using. They are quite right to do it the way they are doing it, but
they really are leveraging the ASP loophole alot. They are actually
doing the integration with GTM, in a GPL script, that exposes a TCP/IP
interface to the same calls. In fact this design is the reason the
AGPL was created.
-FT
--
Fred Trotter
http://www.fredtrotter.com
K.S. Bhaskar
[KSB] <...snip...>
> There is also no reason that you would need to open source everything.
> You could keep your cache module proprietary. GTM actually does this
> with its non-Linux binaries, (or it used to) and that is totally
> legit.
SPARC Solaris, HP Itanium HP-UX & Linux, and HP PA-RISC HP-UX *is not*
FOSS. It is available on reasonably priced traditional user based
software licenses. GT.M on x86/x86_64 Linux, HP Alpha/AXP OpenVMS and
Tru64 UNIX *is* FOSS - currently GPL v3 & going to AGPL v3.
There is a wrinkle on GT.M for x86_64 Linux - the source code is
released (the same tarball can be used to build for x86 32-bits and
x86_64 64-bits). However, while the 32-bit binaries are freely
available at Source Forge, 64-bit binaries that we build, test and
support are provided by us only to customers with support contracts.
Anyone who wants 64-bit binaries but doesn't want a support contract,
will need to compile from source.
Regards
-- Bhaskar
rtweed
sounds like there are some misconceptions.
The GT.M-side code is simply bog-standard MUMPS code that OPENs, USEs
and CLOSEs standard ports - nothing really different from any MUMPS
application code that anyone might feel free to write on a GT.M
system.
All the action really takes place in the MGWSI service component which
is a quite separate module/process and nothing to do with GT.M (or any
other server) at all. The MGWSI service component looks after the
management of TCP socket connections to the server(s), distribution of
requests across available connections, opening new connections on
demand if required, closing them down if required. It contains all the
configuration, logging and error reporting functionality.
What is at the other (client) side of the MGWSI service is actually
unknown and irrelevant to a GT.M server. PHP, JSP, ASP.Net, etc
communicate with the client interface of the MGWSI service. MGWSI
acts as a mediator between the two endpoints and normalises their
behaviour as far as the GT.M (or other server) is concerned. The GT.M-
side code neither knows nor cares whether the client request
originated from PHP, Java, some ASP.Net language, Python, Ruby or
whatever: the requests all look the same to it and what it sends back
to the MGWSI service component is always the same irrespective of the
client technology. So a GT.M system could, if you wanted, be
integrated simultaneously with client front-ends running in PHP, Ruby,
Java, etc etc and it would quite happily interoperate with the lot.
Indeed MGWSI is actually designed to be a totally general-purpose
mediator capable of pretty much linking anything to anything. Some
folks are even using it to integrate legacy DSM applications with
WebSphere MQ.
Hope this helps
Rob
K.S. Bhaskar
I think perhaps you misunderstand AGPL v3. Quoting from section 13:
"... if you modify the Program, your modified version must prominently
offer all users interacting with it remotely through a computer
network (if your version supports such interaction) an opportunity to
receive the Corresponding Source of your version by providing access
to the Corresponding Source from a network server at no charge,
through some standard or customary means of facilitating copying of
software."
So, if someone is serving an application with a modified GT.M over a
TCP connection, AGPL v3 would oblige them to make available the source
code to their modifications. However, there is no obligation to make
available what is on the other side of the connection, i.e., the
process talking to the modified GT.M over TCP. The loophole in GPL v3
that AGPL v3 fixes is that GPL v3 would allow the use of the modified
GT.M in this "ASP" environment without an obligation to make the
source code available.
Regards
-- Bhaskar
Fred Trotter
-FT
--
Fred Trotter
http://www.fredtrotter.com
kdt...@gmail.com
and utilize mumps. I am surprised that you are not reacting more
about a new-found ability. I am seeing much more written about
licensing here than coding ability. The php <--> GTM on the web site
says that this is a FREE download. Are you worried that it is a trap
of some sort? Are you looking a gift-horse in the mouth?
Kevin
Fred Trotter
time is not costless. I will invest it only in projects that offes to
share ownership with me.
If Bhaskar decided to only allow GPL GTM downloads with "club
memberships" that cost $100 a year, I would still consider it a better
investment to spend two months learning MUMPS, and pay for GTM to get
GPL code.
That still seems like a better investment than spending 0 dollars and
10 minutes looking at a free download.
I write a website about just this issue GPLMedicine.org
In answer to your question: I always look at Trojan horses "in the
mouth" < because mixing metaphors is fun :)
-FT
--
Fred Trotter
http://www.fredtrotter.com
rtweed
it's hard to even give stuff away these days without people being
suspicious. Timeo Daneos et donna ferentis.
We only make our money from support and consulting, not directly from
our software. Although my time is not costless either, I've
nevertheless invested a huge amount of it into creating sufficient
documentation, examples, self-training information, pre-built virtual
appliances etc into making it possible for someone who is willing to
invest a small amount of their time to be able to use our products
without any further direct assistance from us.
Purchasing support or consulting from us is not a requirement of using
our products - nowhere is that stated or implied on our web site.
Purchasing support and consulting from us is simply an option. We
work on the basis that ultimately a proportion of our user base will
eventually require the very high quality and responsive support and
consulting advice for which we're renowned and upon which we've built
our business and reputation. Our business model works and we make
what I believe to be an extremely honest living by supporting those
who ask us to support them. If someone uses our products and never
contacts us, our attitude is good luck to you and we're glad if our
software's made a difference.
The only difference between our commercial model and open source is
that we currently choose not to make our core source code available
(though lots of peripheral stuff is), the reason being simply to
protect our core intellectual property.
Anyway, tried and tested enterprise-grade GT.M integration with PHP,
Java, ASP.Net, Python and Ruby is there if you want it for free.
No such thing as a free lunch, or willing to look a gift horse in the
mouth? The choice, in the end, is yours to make.....but of course it
won't cost anything to find out which it is :-)
rtweed
my terrible spelling which should, of course, have been:
"timeo Danaos et dona ferentes"
K.S. Bhaskar
> Fred, you initially seemed concerned that you couldn't program in php
> and utilize mumps. I am surprised that you are not reacting more
> about a new-found ability. I am seeing much more written about
> licensing here than coding ability. The php <--> GTM on the web site
> says that this is a FREE download. Are you worried that it is a trap
> of some sort? Are you looking a gift-horse in the mouth?
more permissive than a GPL. For years, the Windows NT (and maybe
2000) TCP stack was actually FOSS code that Microsoft used in a non-
FOSS product.
Regards
-- Bhaskar
K.S. Bhaskar
stack was code used under a BSD (Berkeley Software Distribution)
license which is permissive enough to allow FOSS code to be
incorporated into a non-FOSS application. The GT.M PHP client is
available under a BSD style license (it is a BSD license only when it
comes from UCB, otherwise it's a Berkeley style license) to allow the
code to be used by FOSS and non-FOSS applications when accessing a
GT.M database.
-- Bhaskar
Fred Trotter
>
> Sounds like yet more misconceptions that need to be clarified.
Nope. I just disagree with you.
> Boy
> it's hard to even give stuff away these days without people being
> suspicious. Timeo Daneos et donna ferentis.
I enjoy communities that regularly quote latin. :)
>
> We only make our money from support and consulting, not directly from
> our software. Although my time is not costless either, I've
> nevertheless invested a huge amount of it into creating sufficient
> documentation, examples, self-training information, pre-built virtual
> appliances etc into making it possible for someone who is willing to
> invest a small amount of their time to be able to use our products
> without any further direct assistance from us.
So far so good.
>
> Purchasing support or consulting from us is not a requirement of using
> our products - nowhere is that stated or implied on our web site.
> Purchasing support and consulting from us is simply an option.
I have no problem with you getting paid. So my concern is not, and
will never be, that you make money on the deal. Unless you making
money by trapping people with your software.
I have suggested to Bhaskar many times before that he should be more
aggressive about the "freeloader" problem. I am pleased to see the
32/64 bit divide, that is a great line in the sand for paid/unpaid
support.
Someday I will write an article about this too, but people who
download and use software for free, without contributing anything
back, I feel are little more than leeches on the community.
> We
> work on the basis that ultimately a proportion of our user base will
> eventually require the very high quality and responsive support and
> consulting advice for which we're renowned and upon which we've built
> our business and reputation.
Or they will require a change to your software. A change that only you
can make because only you have the sourcecode. This is the problem.
Your business model is support *but only you can provide it*. So this
is about control. You have it. Your users do not.
> Our business model works and we make
> what I believe to be an extremely honest living by supporting those
> who ask us to support them.
Alot of people take my criticism as an attack on them personally,
which is unfortunate. I am really trying to talk about the problems
with the model itself.
Consider a Casino. The manager is an honest hard working guy. He works
his shift and takes home the "bacon" to his wife and kids. I do not
have a problem with him.
The Casino itself is also "honest". They tell you what your odds are
upfront. So you know that if you put a dollar in you know that you are
going to get 60 cents (or whatever) back.
But just because everyone involved is honest, does not mean that the
fundamental business is morally OK. I am obviously not interested in
getting into a debate about casinos, or whether gambling is immoral,
but rather to note that there are other industries where "the morals
around the model" are the debate, rather than the morals of a
particular person in the model.
The moral issue in gambling is that our brains are poorly wired to do
the math that makes it apparent that gambling is typically a bad idea.
The moral issue here is that software, especially medical software,
always needs to be changed. Only a proprietary vendor can change the
software. Because you are an honest hardworking guy, there is no
change in your foreseeable future that would cause you fall down on
the job and not make a change that was required. But then, no one
really "forsees" their own death, or the bankruptcy/buyout of the
company that they worked to build. Further, these events WILL happen.
When they do, those relying on your software will not be able to make
the changes they require. In other industries, the resulting migration
is measures in dollars and cents. In medical software, the resulting
migration could be paid with human suffering.
> If someone uses our products and never
> contacts us, our attitude is good luck to you and we're glad if our
> software's made a difference.
You should add:
"But if you ever need changes, we are the only people who can do that for you."
>
> The only difference between our commercial model and open source is
> that we currently choose not to make our core source code available
> (though lots of peripheral stuff is), the reason being simply to
> protect our core intellectual property.
"intellectual property" is largely meaningless to those on this list
with my bent. Copyrights do not work like trademarks, trademarks do
not work like patents, and none of the tree work like "property" in
the real world. For instance, if I give you a shovel or a house, you,
and only you can "own" that house or shovel.
When you say intellectual property you are actually making an
implication that even though nothing "intellectual" works anything
like anything "property" you should be able to make arrangements to
control the scarcity of that resource, as though it were "property".
Of course after making this clever shift of focus, then you can easily
then argue that it needs "protecting", the same way that locks and
alarms protect our homes and cars. The problem is that this
"protection" means that your users lose software freedom.
>
> Anyway, tried and tested enterprise-grade GT.M integration with PHP,
> Java, ASP.Net, Python and Ruby is there if you want it for free.
free as in costless. Not as in freedom.
>
> No such thing as a free lunch, or willing to look a gift horse in the
> mouth? The choice, in the end, is yours to make.....but of course it
> won't cost anything to find out which it is :-)
I already know what it is and so does everyone else. What we disagree
about is the appropriateness of the deal.
Just as some people think Casinos are immoral, I think your whole
model is immoral. (Not you mind you, but your model)
Your software quality is probably good. You do sound like you know
what you are talking about.
However, you are offering a costless option that restricts users freedom.
Thankfully people like me have a much better option than giving up our
freedom. We can work or wait.
I am not going to work on this (I am working on other relevant stuff
however) but thankfully, someone else who agrees with me eventually
will.
When they do, people will be able to choose between your solution,
(good software, costless use, proprietary license) and a
free-as-in-freedom
option (good software, costless use, FOSS license). Which one would you choose?
It does not really matter if you agree with me or not.
My way wins in the end because of economics anyway.
Skip Ormsby
"Someday I will write an article about this too, but people who
download and use software for free, without contributing anything
back, I feel are little more than leeches on the community."
-skip Montani Semper Liberi
Fred Trotter
I will try to fix this soon however...
watch this space.
-FT
--
Fred Trotter
http://www.fredtrotter.com
Gaber, Roy G.
reporting an error, etc.
Skip Ormsby
-skip Montani Semper Liberi
rtweed
>(good software, costless use, proprietary license) and a
>free-as-in-freedom option (good software, costless use, FOSS license). Which one would you choose?
does what it says on the tin, particularly if that's all I want from
it.
By way of example, personally I choose to use VMWare over open source
VM alternatives because I'm safe in the knowledge that it's been well
tried and tested by lots of big boys running mission-critical
situations, it does everything I need it to do, has never let me down
and, critically, it comes with high quality documentation and there's
good availability of free support information that I can google to
ensure I get an answer to any issues I'm grappling with. I also know
that I'm safe in the knowledge that if push comes to shove, there's
someone I can pay to get me sorted out as a priority.
If there's no FOSS alternative, in my experience most people are
usually happy with free, proprietary software if they need or want to
get something done today and aren't prepared to wait and hope for
something that may or may not transpire and may or may not be fit for
purpose and sufficiently reliable for their business requirements. It
depends, I suppose, on your priorities.
Jim Self
I do want to try it, but it would be best if I could just load the relevant files onto a server or virtual machine I already have configured with Linux/Apache/GT.M/M2Web/VistA.JimI agree that EWD seems worth investigating. (Sorry, Rob, but I haven't gone very far with that yet. When I last tried, there were some issues with getting the appliance to load in Parallels on my Mac.)No problem. You might want to try the latest Virtual Appliance. The network driver it uses seems much more reliable
***Oops, it appears that EWD is NOT Open Source!***
I started to download then stopped when I encountered a license agreement that mentions trade secrets and prohibits derivative works, reverse engineering, etc.
What advantages do you see in generating dynamic HTML, Javascript, etc for VistA from php instead of doing it from mumps?The philosophy of EWD is that it doesn't and shouldn't matter where the actual markup, Javascript etc is being served up from. It abstracts that away from you so it's largely irrelevant.
Hmmm. You seem to be saying that the primary source code of VistA/EWD/PHP applications would contain virtually no PHP.
We seem to be abstracting differently but hopefully with some compatibility and complementarity.
One major focus of my interest is on code derived or generated from metadata and/or in combination with actual data. Of course, in M *everything* is data. ;)
M2Web contains a variety of tools that might greatly enhance or simplify any web and M based applications, including those built around EWD.
For instance, a light weight query tool that enables concise and user-modifiable specification of complex queries on M-data with results returned in (potentially) any document type, including HTML, XML, and various Javascript object forms (JSON). This and related tools could reduce the specification of a large class of grids, other data enabled widgets, and data entry forms, to little more than a list of data field identifiers.
I read the pdf. It does look interesting, but not obviously simpler than the code for working with Dojo. I am looking at ExtJS. I need to see some deeper examples.The real advantage of EWD is that it makes the task manageable and scalable. With increasingly complex UI functionality becoming possible with the latest generations of Javascript-based widgets from the likes of Yahoo, Dojo, ExtJS etc, the pages you have to serve up become increasingly complex to write and (critically) to maintain. That's where EWD's Ajax framework comes in - it simplifies how you conceptually design your pages, and also where the custom tags come in, because they can simplify the complex JSON-structured Javascript coding required for these widgets down to a bunch of simple to use and simple to understand XML tags. Witness the EWD/ExtJS desktop which you can get working with just 2 custom tags: see http://gradvs1.mgateway.com/download/extjs4.0.684.pdf, page 34.
questions -
- imprecise dates? Imprecise dates, such as 1978 or February 2002, are important features of medical histories. They can be represented cleanly with Fileman dates, but not by run-of-the-mill date representations used with most date picker widgets.
- non-Caché data? Fileman data? EWD examples of data all use
proprietary Caché features
- data enabled select/combobox?
- data mapping for large data files? examples map data to small
local arrays
- data mapping for Fileman?
- data mapping for view2?
I am sure that it could. What exactly does EWD need from PHP? It might be that the same thing could be provided from M2Web.A separate question is whether EWD could be made to work with GT.M without the need for PHP.
ExtJs looks very good on the surface, but I have not seen any good examples yet with large or complex remote data.The model there would be akin to WebLink and Cache. That's something I'm currently pondering. However, as people who use EWD with Cache know, there would be no difference within your EWD pages: whether and how an EWD application runs with PHP, CSP, JSP or WebLink is handled by EWD's compiler and makes no difference to the developer.Or might you be doing both? That might be relatively easy with EWD and/or M2Web?Plus, it has custom tags to make use of javascript toolkits like extJS.Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few links from google comparing them but all from before Dojo 1.0.Opinions may vary but my view is that ExtJS has become the leader and everyone else is now playing catch-up with them. The latest ExtJS widget library is nothing short of stunning and unbelievably sophisticated.
Examples, please. How would EWD make it more do-able and maintainable than alternative ways of using ExtJS or Dojo?From what I've seen of the current CPRS interface, there's not one bit of functionality that couldn't be done using ExtJS widgets. The problem is that it would involve some very complex use of the ExtJS widgets, but the good news is that EWD would make it do- able and maintainable.
I agree with your last sentence and perhaps with the intent behind the previous one, but it is not clear why your M based toolset or approach is better (or less "hacked-together") than all others.I'm afraid that the days of the hacked-together MUMPS routine to generate web pages are out the window when you're into this level of UI sophistication. You need a tailor-made toolset to make it practical, manageable and maintainable and avoid going insane!
I built some preliminary M2Web tools a while back for generating and processing Dojo based data entry forms for VistA from Fileman data definitions and API's. These can be used to make applications with very little source code.One of the problems is not that any one bit of coding is particularly complex, it's that if you attempt to emulate something like the CPRS interface, you end up with so much stuff to write, manage and maintain.
The amount of stuff required to be written for a given system or task can easily differ by one or more orders of magnitude depending on the conceptual style and approach of the developers involved and the toolsets.
You need automation tools like EWD to allow you to conceptually simplify the process and allow you to crank out the pages. And of course you need to maintain state and security, all stuff done automatically for you by EWD so that burden is relieved also.
Actually, I *was* referring to an automation tool. I would like to see *how* EWD would simplify the tool or the process.
Also, M2Web typically maintains state and security based on user characteristics defined in M data, such as the VistA user file. What sort of compatible mechanisms are provided by EWD?
Unfortunately the version I started with (Dojo 0.43) lacked some of the functionality I would like to see in a full scale data interface and upgrading to the current version (1.1) requires significant re-learning and re-programming. Their data API's and data enabled widgets have changed greatly between versions.I think it's safe to say that the Javascript widget world is advancing at a blistering pace. One more reason for custom tags: to abstract the physical implementation so the underlying code can be kept up to date with the widget libraries whilst their use in your pages can remain relatively constant.
I totally agree on the value of abstraction.
How extensible are the custom tags? How would I extend them?
Yeah, very cool stuff this web 2.0 I agree. There seem to be many ways to go about developing it. So much to learn and so little spare time to do it in......so anything that can make lighter work of it has got to be a good idea, right?Still there must be some commonality in the different approaches...If you keep a blog reporting your progress and problems along the way (and/or report it to hardhats) it might help to illuminate the way for you as well as others.I know that Steve is doing some great pioneering work with EWD, ExtJS and Vista, so I too am looking forward to what he'll be able to demonstrate in the hopefully not too distant future
-- --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Information Technology Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) --------------------------------------- M2Web Demonstration with VistA (http://vista.vmth.ucdavis.edu/) ---------------------------------------
Steve Owen
consider..." who is 'we' ? You are expressing a personal opinion,
correct?
On May 28, 12:04 pm, "Fred Trotter" <fred.trot...@gmail.com> wrote:
Steve Owen
http://groups.google.com/group/ewd-and-vista
Just got back from vacation, so give me a week or two and I'll start
posting code examples and screen shots.
> represented cleanly with Fileman dates, but not by run-of-the-mill
> date representations used with most date picker widgets.
> proprietary Caché features
> * data enabled select/combobox?
> * data mapping for large data files? examples map data to small
> local arrays
> * data mapping for Fileman?
> * data mapping for view2?
rtweed
Let me answer a few of your specific questions. Others will probably
get answered for you when you see the kind of things Steve is doing
with ExtJS/EWD with VistA (note his new Google Group which I'd
encourage you to join)
> I started to download then stopped when I encountered a license
> agreement that mentions trade secrets and prohibits derivative works,
> reverse engineering, etc.
privately if you have any specific concerns or issues.
> Hmmm. You seem to be saying that the primary source code of
> VistA/EWD/PHP applications would contain virtually no PHP.
>
> We seem to be abstracting differently but hopefully with some
> compatibility and complementarity.
>
of static HTML - you can use any text editor or HTML editor for this.
These pages are compiled into the run-time code needed to generate
that markup. If you compile to PHP, then EWD's compiler generates all
the PHP code that's needed to create the markup you defined. It also
generates the call-backs via the MGWSI gateway that are needed to
invoke your pre-page scripts (which fetch data for the page) and
action scripts (which return date to the GT.M back end and validate
it, save it etc).
No markup is usually generated on the fly within GT.M. You will
often, however, have data-driven markup in your pages (eg rows in a
table generated from a resultset). For this you'll use EWD's in-page
scripting tags such as <ewd:forEach> and loop through a session array
which you'll typically create in a pre-page script.
So, yes, it's a very different abstraction model from the one you use.
> One major focus of my interest is on code derived or generated from
> metadata and/or in combination with actual data. Of course, in M
> *everything* is data. ;)
>
concept of data binding. IMHO this is an evil technique and the root
of everything that is wrong in conventional web app development tools.
For more on this see my posting in
http://groups.google.co.uk/group/enterprise-web-developer-community/browse_thread/thread/42278e84daa5b7a8#
> > Witness the EWD/ExtJS desktop which
> > you can get working with just 2 custom tags: see
> >http://gradvs1.mgateway.com/download/extjs4.0.684.pdf, page 34.
>
> I read the pdf. It does look interesting, but not obviously simpler than
> the code for working with Dojo. I am looking at ExtJS. I need to see
> some deeper examples.
deficiencies, the main one of which is that it is based around a
Javascript DOM parser which rewrites the Dojo tags you send to the
browser in real time. The result in most browsers is that you see
your stuff appearing and looking ugly, then the final stuff pops up
and replaces it a moment later. That behaviour just looks nasty to
most people.
Also you have to go through some nasty hoops if you use Dojo tags in
an Ajax-based application (EWD's Dojo tags hide all this away from
you).
Having worked in depth with both Dojo and ExtJS, my conclusion is that
there really is no question about it - ExtJS just blows Dojo away in
terms of utility, sophistication and appearance.
The problem is the complex and tedious Object-oriented Javascript you
use to define ExtJS widgets. The parameters you require to define a
widget are all over the place and often repeated in several places,
and of course you often need target tags in the page too. By defining
custom tags for ExtJS, EWD allows that to all disappear, so you end up
with something that's as simple as Dojo to specify without all the run-
time deficiencies.
>
> questions -
>
> * imprecise dates? Imprecise dates, such as 1978 or February 2002,
> represented cleanly with Fileman dates, but not by run-of-the-mill
> date representations used with most date picker widgets.
> proprietary Caché features
> * data enabled select/combobox?
> * data mapping for large data files? examples map data to small
> local arrays
> * data mapping for view2?
>
should come out in Steve's examples
> Also, M2Web typically maintains state and security based on user
> characteristics defined in M data, such as the VistA user file. What
> sort of compatible mechanisms are provided by EWD?
decide what stuff to persist in your session using APIs that EWD
provides. Otherwise it's all transparent and "just works"
> I totally agree on the value of abstraction.
>
> How extensible are the custom tags? How would I extend them?
of the custom tags you define. They are the means by which you can
take control of EWD and add whatever level of power you like to it.
Of course, they are inevitably the domain of the advanced "power-user"
and require considerable knowledge of EWD, Javascript and XML DOM
processing.
Indeed, with reference to a comment by Fred Trotter, apart from bug
reports, there's very little likelihood of anyone requiring me/
MGateway to make any amendments to EWD, since the whole idea of its
architecture is to allow you to extend its functionality in whatever
way you wish through custom tags. After 6 years of solid commercial
use by a wide range of customers, most of the generally required basic
features are now present and bedded down in EWD, so its unlikely that
a typical user is going to come up with anything that isn't already
catered for. Most everything else can be achieved by defining and
writing custom tags.
For more information see the EWD documentation on custom tags and also
the following postings:
http://groups.google.co.uk/group/enterprise-web-developer-community/browse_thread/thread/405fd28fda1d47c7#
http://groups.google.co.uk/group/enterprise-web-developer-community/browse_thread/thread/ed567a15de2d692b#
Basically EWD gives you access to the very same mechanisms I've used
myself for creating the custom tags EWD provides for you "out of the
box".
I'm in the process of completing a training course on this very
subject if anyone's interested - contact me by email for details and
costs.
Rob
K.S. Bhaskar
I am not sure whether you monitor this group or whether you just did a
one-of post. Any answers about the server side technology would be
appreciated. Also, I wrote to you directly about the 17th VistA
Community Meeting (http://worldvista.org/Conferences/17th-vista-
community-meeting) but never got a reply, so I wonder if my e-mail was
caught by your spam trap.
Regards
-- Bhaskar
On May 22, 4:16 pm, "K.S. Bhaskar" <ksbhas...@gmail.com> wrote:
> Thanks, David. I am curious about your server side technology. Did
> you use Kevin O'Kane's MUMPS to C translator to translate VistA to C?
> Anything you can say to explain your server side technology would be
> appreciated.
>
> Regards
> -- Bhaskar
>
> On May 22, 3:27 pm, daviduhl...@gmail.com wrote:
>
> > I wanted to weight in here so that there can be some on-record
> > discussion coming from us directly. I do not in any way want to offer
> > a general commentary on why some people want to use MUMPS or don't
> > want to, or X language is better than Y, I am not looking to instigate
> > a flame war or really say that what we are doing is a better or worse
> > approach from a technical standpoint than anything else. It is the
> > right approach for us. Additionally I need to make clear that this is
> > a preliminary announcement, we have moved beyond proof of concept but
> > there is still a lot to be done. We now have 2 beta sites we will be
> > rolling out over the course of the next 12-18 months while actively
> > seeking 1 or more additional sites.
>
> [KSB] <...snip...>
Fred Trotter
On Thu, May 29, 2008 at 10:34 AM, Skip Ormsby <skip....@gmail.com> wrote:
> Fred, I think I would think about rephrasing this quote:
>
> "Someday I will write an article about this too, but people who
> download and use software for free, without contributing anything
> back, I feel are little more than leeches on the community."
>
> I down load and use *For Free* Real Player, Quick Time, Java, FoxIt, etc.
Except for Java, none of these software products are "free software"
in the free as-in-freedom sense.
You do not owe these software products anything because they have not
given you anything. The owners own the software and you are user
without control. "Contribution" does not make sense without
Free-as-in-freedom software of one sort or another.
As for Java, you can easily contribute to this project by supporting
Fedoras ongoing efforts to produce a fully "free-as-in-freedom"
implementation of Java, that the other distros are quickly adopting.
Here is a web-link for donating to Fedora.
http://fedoraproject.org/wiki/Contribute
I like to buy t-shirts or DVDs to support Fedora.
-FT
> and there ain't no way can contribute to the code or is there a Contribute
> button, therefore I am a leech. Kinda of rude to say the least.
>
> -skip
> Montani Semper Liberi
>
> Fred Trotter wrote:
>
Fred Trotter
> If there's no FOSS alternative, in my experience most people are
> usually happy with free, proprietary software if they need or want to
> get something done today and aren't prepared to wait and hope for
> something that may or may not transpire and may or may not be fit for
> purpose and sufficiently reliable for their business requirements.
It is amazing that you fail to consider the "ethical middle". You can
easily use VMWare while contributing to XEN (or whatever). This is not
a binary decision.
> It
> depends, I suppose, on your priorities.
>
> >
>
--
Fred Trotter
http://www.fredtrotter.com
Fred Trotter
are compatible with the Free Software Community.
Those ideals are explained at http://fsf.org
Granted, not everyone in the GTM or VistA community also consider
themselves members of the Free Software Community (i.e. those that
generally believe in the four freedoms) but there are enough of us out
there that I can safely say "we" as long as I am arguing the central
FOSS arguments, and not my own crazy ideas (I try to label those as
such)...
-FT
On Tue, Jun 3, 2008 at 7:57 AM, Steve Owen <st...@stevenowen.com> wrote:
>
> Fred, I'm curious, when you say "There is no way that we would
> consider..." who is 'we' ? You are expressing a personal opinion,
> correct?
>
--
Fred Trotter
http://www.fredtrotter.com