GUI and MUMPS
George Grodentzik
Has someone had experience with the diffrent ways a GUI front end
can be added to MUMPS. More specifically what the major differences
between ISM implementaion and MSM. Which one of the two runs faster?
Are there any other options available that are used alot in the field
Renee Wimmer
So many different ways.....
It all depends on what you want to do, how independent
you want to stay, and whether or not you're willing to
learn a few more programming languages.
If you want to stay 'completely M', then you're probably
best off with MSM-Workstation.
If you want to go Inter/Intranet or NetPC, then you should consider
HTML+Java and either PDQWeb from Micronetics or M/Weblink from
Intersystems.
Other than that, you have various options, such as Visual Basic, Delphi
etc.
As far as which one of the two runs faster, there was an MWAPI Article in
the German
M-Boerse (M-Users Group Germany Newsletter) in the December 1996 issue
which did a comparison between MSM 4.07 with MSM-GUI 2.0 and
DTM 6.2 with DT-WIN 2.2 which stated that the load time for MSM was 6 sec.
and DTM 44 sec. These however, are outdated products, and I'm not aware of
any newer comparisons.
In any case, if you're an 'oldtimer' at M, you'll definately have to start
learning
and thinking 'event driven' programming.
Renee Wimmer re...@comtrix-net.com
COMTRiX GmbH http://www.comtrix-net.com
Germany
George Grodentzik <geo...@adsc.com> schrieb im Beitrag
<970613192...@adsc.com>...
Gardner S Trask
George Grodentzik <geo...@adsc.com> writes:
>Has someone had experience with the diffrent ways a GUI front end
>can be added to MUMPS. More specifically what the major differences
>between ISM implementaion and MSM. Which one of the two runs faster?
>Are there any other options available that are used alot in the field
George, your question is too "big" for a single answer. There are dozens
of proven solutions for putting a GUI front end on your M system. Some
include; Delphi, Powerbuilder, Visual Basic, MWAPI, Java, Active X
components, HTML scriupting from M, X-terminal, etc. And until you decide
which, there is no way to compare back-end vendors.
I am sure your post will elicit some sucess stories.
Good luck
Gard
--
'' Gardner S. Trask III tr...@world.std.com
O\/O "First .cultured man on the Internet" alt.culture.gard-trask
( ) Creator of 'Circut, the Internet Owl(tm)'
"" Newbie Netiquette mascot and the 'lectronic Martha Stewart
Rob Tweed
>If you want to stay 'completely M', then you're probably
>best off with MSM-Workstation.
>
>If you want to go Inter/Intranet or NetPC, then you should consider
>HTML+Java and either PDQWeb from Micronetics or M/Weblink from
>Intersystems.
>
Since the current trend is for "thin clients", then opting for a
web-based approach has got to be the most sensible.
If, like, me, you agree with Jon Udell, the guy who does the
devlopment for Byte Magazine's web site, then forget client-side Java
and opt instead for HTML and JAvaScript on the browser - his article
this month is worth reading - but try WebLink with M at the back end
instead of server-side Java "servlets"
If you want to keep your M web gateway as Open as possible, opt for
Weblink as it supports virtually all flavours of M on most platforms,
and supports both Netscape and Microsoft web servers.
...and watch this space for more Weblink developments beyond v2 which
is due for imminent release from Intersystems.
---
Rob Tweed
Nucleus Design Ltd : http://www.nucleus.co.uk
M/Gateway Developments Ltd : http://www.hwsl.co.uk/mgw
---
Paul Perrin
> devlopment for Byte Magazine's web site, then forget client-side Java
> and opt instead for HTML and JAvaScript on the browser - his article
> this month is worth reading - but try WebLink with M at the back end
> instead of server-side Java "servlets"
It seems to me that servlets are a Java step towards the permanently
running M environment (cutting out the main 'cost' of CGI processing
(process startup) - while preserving the security and stability of
separate address spaces).
But, M is already there, it is already a good multi-user, multi-process
systems (good on paper - and _very_ importantly, it has proven to be
good in *practice* over many years on many sites and many networks).
A huge positive step for M would be for it to be made a serious force in
webserver processing.
Giving M programmers the opportunity to leverage their skills on to the
web is likely to be *very* attractive to the individuals, and as those
of us who have used M as a server backend (regardless of which product
they have used!) know -- M is way ahead of the competition (at the
moment), we must make sure that M does not become 'the best kept secret
on the web' !
The thinner the interface between the web an M, the better M can show
itself off as a natural language for the web. Admittedly, some simple z
extensions for TCP/IP and socket handling would be useful, but in most
areas M is already way ahead of the competition.
It is important that people don't wait for things to happen -- they must
be ready ahead of time -- Imagine if MWAPI had become established, and
that most M'sters had learnt it when it was first specified... A
netscape plug in for 'net-mwapi' would have meant that M could have been
an established, mature WIMP web client technology with an established
group of experienced developers, before JAVA had got out of bed.
The rest of the IT world will (probably, eventually) catch up with all
of M's special features -- so far M has been fortunate that much of the
competition has developed featuritus and bloatwareism (some languages -
such as ADA - have suffered from these afflictions before they were ever
released!), the strict hand of the MDC has prevented M going down those
particular dead ends.
M'sters must be given the tools and opportunities to put M based sites
on the web, so M can shine in the 'net environment - as it deserves.
Paul Perrin /)/+)
***
Admatic by Immediate Data Ltd
Global, National, Local, Fresh, Fast, Free Classified Ads
Instant Insertion, Instant Searching, Easy Browsing
***
ps. If you like the stuff I write, you can read more by joining the
MTA - UK & Ireland where I a regular column in newsletter -
details at http://www.mtauki.co.uk or email in...@mtauki.co.uk.
If you don't like the stuff I write, well there are plenty of other
reasons to join the MTA - check out the website, and order an
information pack.
pps. If you really like the stuff I write, I am currently available
Immediately for contract consultancy, analysis and programming-
email me for more info.
Jim self
Renee Wimmer wrote:
> In any case, if you're an 'oldtimer' at M, you'll definately have to
> start
> learning and thinking 'event driven' programming.
Web applications seem to me to be an entirely different direction.
Working with HTML & HTTP, the micro-events of GUI programming can be
largely ignored since they are handled by the browser. Instead, you work
at a higher level with macro-events, a complete request for some report
or input from a data input form. This is very different from tracking
mouse events or individual keystrokes.
--
Jim Self jas...@ucdavis.edu
VMTH Computer Services, UC Davis
http://www.vmth.ucdavis.edu/us/jaself
http://vmacs.vmth.ucdavis.edu/notebook/MUMPS
http://vmacs.vmth.ucdavis.edu/notebook/MHTTP
Eduardo Augusto Gouveia dos Santos
Renee Wimmer wrote:
>
> So many different ways.....
> It all depends on what you want to do, how independent
> you want to stay, and whether or not you're willing to
> learn a few more programming languages.
>
> best off with MSM-Workstation.
>
> If you want to go Inter/Intranet or NetPC, then you should consider
> HTML+Java and either PDQWeb from Micronetics or M/Weblink from
> Intersystems.
>
> etc.
>
> As far as which one of the two runs faster, there was an MWAPI Article in
> the German
> M-Boerse (M-Users Group Germany Newsletter) in the December 1996 issue
> which did a comparison between MSM 4.07 with MSM-GUI 2.0 and
> DTM 6.2 with DT-WIN 2.2 which stated that the load time for MSM was 6 sec.
> and DTM 44 sec. These however, are outdated products, and I'm not aware of
> any newer comparisons.
>
> learning
> and thinking 'event driven' programming.
>
> COMTRiX GmbH http://www.comtrix-net.com
> Germany
>
> George Grodentzik <geo...@adsc.com> schrieb im Beitrag
> <970613192...@adsc.com>...
> > can be added to MUMPS. More specifically what the major differences
> > between ISM implementaion and MSM. Which one of the two runs faster?
> > Are there any other options available that are used alot in the field
> >
We are...
1)Currently running a full GUI application completely designed using
MSM-Workstation for Windows. This application has an average of 64 users
but the system is conceived to hold 128. Clients are running an
executable which is stored on an UNIX application server and they access
another UNIX database server.
2)Final testing our internet/intranet solution which has both an HTML
and GUI interfaces. The internet GUI solution is also based on MSM-WFW.
3)Proud that the whole system can NOW be accessed by any front-end tool
(be it java, vb, delphi, etc). The design process insulated the database
interface from the front-end details. You can call this a 'somewhat OO'
approach.
4)very happy to say that most of the network traffic generated by the
system is due to the access client workstations do to fetch the
executable and DLLs on the application server.
Yes the application runs really very fast.
No, on the whole development process no one had to learn a new language.
Yes, GUI development is VERY different from dumb terminals stuff - but
it is from that kind of work that we earn our living.
Please feel free to stress any point!
--
Eduardo Augusto Gouveia (mailto:cst...@ibm.net)
CompScientia Inf & Tec Ltda Tel: (55)(21)205-4423
Rua Barao do Flamengo, 32/6o Fax: (55)(21)285-7852
Flamengo - Rio de Janeiro - RJ - Brasil
Eduardo Augusto
Jim self wrote:
>
> Renee Wimmer wrote:
>
> > In any case, if you're an 'oldtimer' at M, you'll definately have to
> > start
> > learning and thinking 'event driven' programming.
>
> Working with HTML & HTTP, the micro-events of GUI programming can be
> largely ignored since they are handled by the browser. Instead, you work
> at a higher level with macro-events, a complete request for some report
> or input from a data input form. This is very different from tracking
> mouse events or individual keystrokes.
Sure! It will depend on the final result you would expect from the
application.
If you need your app to run a smart user interface with shortcuts, lots
of inter-field validation but still a "normal comercial" application I
would do it with M on the front-end. Do not forget M愀 portability and
the fact that MWAPI is independent of the underlying windows platform:
you will still be running it after the MS-Windows age. I hope there will
be something new on the future:)
If the app is more like multimedia you may prefer VB or Delphi. They
could provide you more of this functionality but you will be tied to
MS-Windows....
If the question is access by anybody in the internet I would try an HTML
approach. I have the idea (anybody have comments on it??) that Java
would be 1)not a 'de facto' standard 2)not supported by every browser
3)not as flexible as a true GUI approach.
Is this reasonable??
Greg Kreis
Eduardo Augusto wrote:
> If the question is access by anybody in the internet I would try an HTML
> approach. I have the idea (anybody have comments on it??) that Java
> would be 1)not a 'de facto' standard 2)not supported by every browser
> 3)not as flexible as a true GUI approach.
Java is supported in the two major browsers, not sure about the others.
Java Virtual Machines are being put on every major OS out there (even
OS/2 ;). That means you don't need a browser to run a Java application.
Intel is building support to run Java directly into their new CPUs.
Java apps are FAR more GUI than HTML. Java sits on top of the OS' GUI
and maps its AWT to it - it is a universal GUI, not unlike the concept
of MWAPI. Corel developed a complete office suite in Java, so I suspect
its GUI is sufficient, for now.
IBM has made a huge committment to Java, along with many other vendors
(Netscape will be re-writing their browser in Java in 1998).
MicroSoft has started efforts to create a 'lite' office suite written in
Java.
IMHO, Java is not a flash in the pan and will be a dominant language in
the next century.... BTW, did you mean to say JavaScript instead of
Java? ;)
--
---------------------------------------------------------------------
Greg Kreis Pioneer Data Systems, Inc.
gkr...@mindspring.com http://www.mindspring.com/~gkreis/
http://www.hardhats.org/ <-- dedicated to worldwide VISTA/DHCP users
Beware of geeks bearing GIFs.
Rob Tweed
>Beware of geeks bearing GIFs.
..or in the original Latin
timeo Anoraks et toner ferentis
(sorry Virgil...! )
...crikey, I'm getting sadder than I thought possible
Scott P. Jones
At 04:15 PM 6/18/97 -0400, Eduardo Augusto wrote:
>Jim self wrote:
>>
>> Renee Wimmer wrote:
>>
>> > In any case, if you're an 'oldtimer' at M, you'll definately have to
>> > start
>> > learning and thinking 'event driven' programming.
>>
>> Web applications seem to me to be an entirely different direction.
>> Working with HTML & HTTP, the micro-events of GUI programming can be
>> largely ignored since they are handled by the browser. Instead, you work
>> at a higher level with macro-events, a complete request for some report
>> or input from a data input form. This is very different from tracking
>> mouse events or individual keystrokes.
>
>Sure! It will depend on the final result you would expect from the
>application.
>
>If you need your app to run a smart user interface with shortcuts, lots
>of inter-field validation but still a "normal comercial" application I
>the fact that MWAPI is independent of the underlying windows platform:
>you will still be running it after the MS-Windows age. I hope there will
>be something new on the future:)
While M itself is portable, using MWAPI isn't really very portable.
For many reasons, it hasn't gotten very broad support from implementors.
(I could go into the problems with its design, etc. that helped to cause
this situation - but I'll leave that be right now).
>If the app is more like multimedia you may prefer VB or Delphi. They
>could provide you more of this functionality but you will be tied to
>MS-Windows....
That is a reasonable approach - and have been used with great success
by many users of M technology - with all M implementations - but that
approach has a lot of serious drawbacks - rather fat clients, being tied
to MS-Windows, installation hell (.dll's, .vbx's, and .ocx's, and having
the get the right versions of those .dll's and controls), things not working
portably or being available even across the Microsoft platforms (ever tried
to use a TrueGrid control, or a product that depended on one - on a non
Intel Windows NT platform???).
While this may have been the best approach a few years ago - I really don't
think it is any more.
>If the question is access by anybody in the internet I would try an HTML
>approach. I have the idea (anybody have comments on it??) that Java
>would be 1)not a 'de facto' standard 2)not supported by every browser
>3)not as flexible as a true GUI approach.
I think you are wrong here on all points. I would recommend an approach
using HTML/Java/JavaScript with an M backend over any other approach.
With M/Weblink you can use practically any M vendor, and practically any
hardware platform for the M host (the M host and the Web host can be the
same machine on many platforms - such as Win95, WinNT, and various Unixes).
1) Java is already much more of a 'de facto' standard than MWAPI ever was.
2) What browser are you using that doesn't support Java?
NetScape, MicroSoft, Sun, IBM, Oracle, etc. are all crowing about their
Java support...
3) What do you call a "true GUI approach"? What makes one GUI "truer" than
another? What lack of flexibility do you see with Java? You can do
anything from Java that you can do from C if you need to (just add some
native classes, or use MicroSoft's JDirect to gain access to all Win32
APIs - although I'd never recommend it)
Java already has a great deal of support for international applications -
full Unicode support (which makes it tie in very well with the upcoming
Unicode release from InterSystems), and later this year a much better API
for doing GUI programming will be out (based in part on Netscape's IFC
- Internet Foundation Classes) - that will still be just as portable as
Java is now.
Scott Jones
President
Gandalf Software, Inc.
Eduardo Augusto Gouveia dos Santos
Scott P. Jones wrote:
> I would recommend an approach
> using HTML/Java/JavaScript with an M backend over any other approach.
> With M/Weblink you can use practically any M vendor, and practically any
> hardware platform for the M host (the M host and the Web host can be the
> same machine on many platforms - such as Win95, WinNT, and various Unixes).
Can you please inform us the current number of customers already running
apps in such interface in both MSM and ISM (think these are the main M
implementors... Am I right??).
Can you also inform us the number of client workstations the biggest
installation in such a platform has? Of course any additional details
would be very interesting...
> 1) Java is already much more of a 'de facto' standard than MWAPI ever was.
> 2) What browser are you using that doesn't support Java?
> NetScape, MicroSoft, Sun, IBM, Oracle, etc. are all crowing about their
> Java support...
I have read about some difficulties on a new java standart (1.1) to
which Netscape was not entirely commited...
I would really like to hear from somebody else who thinks Java will be
the all purpose language that will open a new age on computing.
Preferably not a vendor.
> 3) What do you call a "true GUI approach"? What makes one GUI "truer" than
> another? What lack of flexibility do you see with Java? You can do
> anything from Java that you can do from C if you need to (just add some
> native classes, or use MicroSoft's JDirect to gain access to all Win32
> APIs - although I'd never recommend it)
These are really very good news. I was refering to HTML, not Java.
Bruce Hulsey
Greetings!
Scott Jones writes:
>While M itself is portable, using MWAPI isn't really very portable.
>For many reasons, it hasn't gotten very broad support from implementors.
>(I could go into the problems with its design, etc. that helped to cause
>this situation - but I'll leave that be right now).
Scott, I for one would love to hear your take on this issue. To my knowledge
there are only two implementors who have even attempted to accomodate MWAPI,
one as the cornerstone of one of their main product offerings and the other as
somewhat of an afterthought add-on to one or two of their M implementations.
It was my understanding that the initial implementations of MWAPI were not
very good performers (and perhaps still are not) and that there were (at least
initially) not good tools for designing MWAPI interfaces. I understood these
to be the primary reasons that MWAPI did not thrive, not that the underlying
design was flawed.
.......
: o/ : Bruce Hulsey
: <| : Univ. of Arkansas for Medical Sciences
: / > : internet: bbhu...@life.uams.edu
:.....: or: br...@myself.com
Gardner S Trask
Bruce Hulsey <BBHU...@LIFE.UAMS.EDU> writes:
>Greetings!
>Scott Jones writes:
>>While M itself is portable, using MWAPI isn't really very portable.
>>For many reasons, it hasn't gotten very broad support from implementors.
>>(I could go into the problems with its design, etc. that helped to cause
>>this situation - but I'll leave that be right now).
>Scott, I for one would love to hear your take on this issue. To my knowledge
>there are only two implementors who have even attempted to accomodate MWAPI,
>one as the cornerstone of one of their main product offerings and the other as
>somewhat of an afterthought add-on to one or two of their M implementations.
>It was my understanding that the initial implementations of MWAPI were not
>very good performers (and perhaps still are not) and that there were (at least
>initially) not good tools for designing MWAPI interfaces. I understood these
>to be the primary reasons that MWAPI did not thrive, not that the underlying
>design was flawed.
I too would like to hear these arguments Scott.
As one of the early advocates for MWAPI I was dismayed when the standard
went to Type-A in a record time of just over one year, only to be ignored
by one of the vendors.
One vendor embraced it and created a tool for easy WISYWIG development.
The other seemed to allow it to starve to death.
Now I would not tilt at this windmill today, but at the time MWAPI was a
great initiative for bringing GUI to M. Visual basic was on version 2.0,
Powerbuilder had not even been released, and Delphi was still a concept. I
liken MWAPI to Visual 2.0. Had people embraced it, and the vendors made it
easy to use and enhance, I think it could really have taken off. One
vendor fought that battle, and I am appreciative to them. Others did not.
Who among us would use visual basic, powerbuilder or delphi if we had to
write all the code by hand, not with painters or toolboxes? And MWAPI
certainly could have grown to accomodate CGI, JAVA script, Active X, etc.
Today, there are too many great options to make a business case for a
home-grown gui, but I firmly believe lack of vendor support (by at least
two vendors) helped kill MWAPI.
By the way, we ARE the first ANSI standard language to have a Windowing
API standard. And put up against Visual Basic, we still have a good amount
of the same gadgets.
Scott, I have never heard of a better solution than the use of SSVN's,
but then I am not privvy to the internal structures of the vendors
products. I look forward to your comments.
John Murray
Scott P Jones wrote:
>While M itself is portable, using MWAPI isn't really very portable.
>For many reasons, it hasn't gotten very broad support from
implementors.
>(I could go into the problems with its design, etc. that helped to
cause
>this situation - but I'll leave that be right now).
Scott, I’d be interested to hear what you perceive the reasons to be.
And other c.l.m readers might have input too.
John Murray
Software Engineer
Micronetics Europe Ltd
Paul Perrin
Eduardo Augusto Gouveia dos Santos <cst...@ibm.net> wrote:
> Scott P. Jones wrote:
>
> > I would recommend an approach
> > using HTML/Java/JavaScript with an M backend over any other approach.
> > With M/Weblink you can use practically any M vendor, and practically any
> > hardware platform for the M host (the M host and the Web host can be the
> > same machine on many platforms - such as Win95, WinNT, and various Unixes).
> Can you please inform us the current number of customers already running
> apps in such interface in both MSM and ISM (think these are the main M
> implementors... Am I right??).
> Can you also inform us the number of client workstations the biggest
> installation in such a platform has? Of course any additional details
> would be very interesting...
I think the flaw with this is the position of M within it. Java already works
as a client language and as a server (cgi or api) language -- where does M fit
in?
Is is just spun off as file/storage API to be called from what ever language
the designer fancies - taking its proven network and multi-access attributes,
but dumping the language and the programmers?
> > 1) Java is already much more of a 'de facto' standard than MWAPI ever was.
> > 2) What browser are you using that doesn't support Java?
> > NetScape, MicroSoft, Sun, IBM, Oracle, etc. are all crowing about their
> > Java support...
> I have read about some difficulties on a new java standart (1.1) to
> which Netscape was not entirely commited...
> I would really like to hear from somebody else who thinks Java will be
> the all purpose language that will open a new age on computing.
> Preferably not a vendor.
I have yet to see a genuine Java application. The specification looks good,
talk is common, but where is all the Java shareware on the internet? Would any
one here have a clue how to install a java app on their computer?
I have installed only *one* java program - it converts files to regurgitated by
a twin java applet on webpages.
If java is so great for development, then where is it?? I understand that some
banks are using it seriously, but then a fair number of banks used (still use?)
NeXT hardware! Niche, niche, niche.
If the Java hype can be maintained for long enough then it will eventually get
a solid foot hold, but it has *NOT* taken the WWW by storm... And now that MS
have decided to reject part of the Java standard, and bastardise the rest of
it, then it may well not be portable anyway, there will be Java and MSJava --
and if you were going to use MSJava, then you may as well go activex in the
first place.
Me? In the past I've done raw windows API from C and pretty/easy windows from
Delphi, but now I've learnt perl and the basics of java (nothing revolutionary,
just a neat-enough repackaging of various programming language concepts).
But, until something comes along that can come somewhere close to DTM
(development speed, execution speed, database speed), then DTM is what I'll
use by preference myself. For clients I'll write in whatever they fancy.
Paul Perrin /)/+)
Scott P. Jones
At 11:48 AM 6/23/97 -0400, Bruce Hulsey wrote:
>Greetings!
>
>Scott Jones writes:
>
>>While M itself is portable, using MWAPI isn't really very portable.
>>For many reasons, it hasn't gotten very broad support from implementors.
>>(I could go into the problems with its design, etc. that helped to cause
>>this situation - but I'll leave that be right now).
>
>there are only two implementors who have even attempted to accomodate MWAPI,
>one as the cornerstone of one of their main product offerings and the
other as
>somewhat of an afterthought add-on to one or two of their M implementations.
>It was my understanding that the initial implementations of MWAPI were not
>very good performers (and perhaps still are not) and that there were (at
least
>initially) not good tools for designing MWAPI interfaces. I understood these
>to be the primary reasons that MWAPI did not thrive, not that the underlying
>design was flawed.
Generally - the *design* is what affects performance the MOST.
The design of MWAPI made it very difficult to get good performance -
the same can be said of Mumps itself. Also, the design didn't fit
very well with the directions the rest of the computing world had
been taking for years before the MWAPI design was even started.
(i.e. message passing or object oriented APIs to GUIs - I started
using a very nice one - in 1985 - on the Amiga). I don't think
there was very much implementor involvement in the design (and
by implementor - I mean a person, such as myself, who actually
implements M, not simply a person who happens to work for a company
that implements M)
Scott
Scott P. Jones
At 12:43 PM 6/23/97 -0400, Steve Lathrop wrote:
>I would even go so far as to say that the design itself seems rather
>elegant.
In what ways do you feel that it is elegant?
Is it easily extensible (and by this I mean at both the syntax level
and the implementation level)?
Are the semantics easy to understand? (i.e. why do things only display when
*certain* nodes are changed, etc)?
Does it easily handle differences in underlying OS support?
Does it lend itself to a high performance implementation?
Is it easy to use it to make encapsulate things (so as to build
reusable components)?
These are just a few of the questions you should ask about the design -
and they are applicable not just to MWAPI - but to M itself (and I'll
leave all of you to decide how Mumps passes muster on these design
criteria)...
Scott
Eduardo Augusto Gouveia dos Santos
Gardner S Trask wrote:
> Now I would not tilt at this windmill today, but at the time MWAPI was a
> great initiative for bringing GUI to M. Visual basic was on version 2.0,
> Powerbuilder had not even been released, and Delphi was still a concept. I
> liken MWAPI to Visual 2.0. Had people embraced it, and the vendors made it
> easy to use and enhance, I think it could really have taken off. One
> vendor fought that battle, and I am appreciative to them. Others did not.
> Who among us would use visual basic, powerbuilder or delphi if we had to
> write all the code by hand, not with painters or toolboxes? And MWAPI
> certainly could have grown to accomodate CGI, JAVA script, Active X, etc.
> Today, there are too many great options to make a business case for a
> home-grown gui, but I firmly believe lack of vendor support (by at least
> two vendors) helped kill MWAPI.
> By the way, we ARE the first ANSI standard language to have a Windowing
> API standard. And put up against Visual Basic, we still have a good amount
> of the same gadgets.
> Scott, I have never heard of a better solution than the use of SSVN's,
> but then I am not privvy to the internal structures of the vendors
> products. I look forward to your comments.
> Gard
Dear Gardner,
I agree with almost everything you state but the idea of MWAPI's death.
Micronetic's Workstation product is based on it and all the customers I
have which run GUIs use MWAPI as the underlying API.
We went on production with the first GUI app on October 94. All MWAPI
based with no help of a builder tool. Of course things now are much
better with MSM-WFW comprising a GUI builder and generating
executables...
Performance was really once a problem. I would report it not to MWAPI
problems though. Micronetics early windowing platform was based on a
interface between their DOS product and MS-Windows API. This platform
was not linear in performance - as far as I could see - due to weak
multitasking suppor on Windows 3.1: imagine that platform trying to run
a DOS app comunicating with an Windows app via an VxD driver. Now
suppose that this 3.1 windows also had to deal with M using an ethernet
card...
My oppinion is that NOBODY was really serious about GUI client/server
app on that moment. All platforms were too much new. Notwithstanding,
MSM-PC already had a front-end with VERY GOOD performance to run what we
had on that moment: CHUI applications.
That front end had DDE support to integrate corporate apps with other
Windows apps. Also GUI support was provided - on the same environment as
the CHUI interface.
This CHUI/GUI integration you can still see on Micronetics front-end
(now MSM-WFW, fully 32 bit windows blablablabla) I can't see on much of
other platforms. More: it's ole automation controler abilities makes it
transparent to the user if one window is from VB and the subsequent is
on M - or vice-versa.
Is VB/Delphi/whatelse better?
I feel everybody went some time ago to a beautiful user interface -
which (tell me if I am wrong) had VERY VERY WEAK network performance. On
that time we had a corporate environment with very good network
abilities. Now VB is no more kids fun - but I can place my application
routines both on client or on server side, use the same programming
language both on server and client, have an application server, database
server, web server, all separate or together in one machine.
And no doubt - we are running it on production.
Arthur B. Smith
"Scott P. Jones" <sc...@intersys.com> writes (about the MWAPI)
> Generally - the *design* is what affects performance the MOST.
> The design of MWAPI made it very difficult to get good performance -
> the same can be said of Mumps itself.
The design deliberately focused more on portability than performance,
as I recall. Similarly, MUMPS language development has not focused
primarily on performance, though it is a consideration that is
weighed into the mix before anything is voted in by the MDC. I won't
say that the MDC has never voted in anything the vendors indicated
would make a "significant" performance hit, but I don't think they've
done it blindly -- they've usually known what they were getting into.
It is interesting, since MUMPS was not designed to get good
performance, that it has such good performance.... Apparently (and
surprisingly) it is NOT "the *design* that affects performance the
MOST." Otherwise we would be in much more desperate straits. I
think this is a tribute to the ingenuity of implementors like Scott,
and also to the importance of making the design optimize
conceptualizing the problem, which is where MUMPS does particularly
well. This in turn leads to "macroefficiency" at the expense of the
"microefficiency", or at least, that's my guess.
> Also, the design didn't fit
> very well with the directions the rest of the computing world had
> been taking for years before the MWAPI design was even started.
> (i.e. message passing or object oriented APIs to GUIs - I started
> using a very nice one - in 1985 - on the Amiga).
I'm not sure I'd agree with this. The MWAPI approach (using _ssvn_s)
really is a message based object oriented API. It is only different
in the programming mechanism for invoking the methods or accessing
the properties of (i.e., sending messages to/from) the objects. In
the MWAPI it is done with SET or MERGE commands rather than an IO
command or procedure call. That's really a fairly trivial syntactic
difference. The effect is entirely the same, I think. Am I missing
something there?
> I don't think
> there was very much implementor involvement in the design (and by
> implementor - I mean a person, such as myself, who actually
> implements M, not simply a person who happens to work for a company
> that implements M)
Well, for that the implementors/vendors have only themselves to
blame. Certainly the MDC representatives from the implementors
played a VERY important role in forging the MWAPI. I would say that
the MWAPI was more vendor-led (as opposed to user-led) than any
other "big ticket" item in my (admittedly brief) experience in the
MDC. If there is some complaint about who the vendors sent as their
representatives, well, that is the vendor's own fault, and I feel no
sympathy there.
For that matter, Scott, when will Gandalf Software, Inc. be sending
a representative (like yourself) to the MDC? As you point out, we
could all benefit from this. You could join the ranks of many MDC
members (myself included) who are funding our involvement entirely
from their own pockets....
-art
------------------------------ 8^) -----------------------------------
Arthur B. Smith a...@vets.vetmed.missouri.edu
Dept. of Vet. Med. & Surg. (573) 882-2666 (voice)
A-353 Clydesdale Hall (573) 884-5444 (FAX)
University of Missouri (573) 642-4768 (Home)
Columbia, MO 65211 >>> Note new area code! <<<
Gardner S Trask
Eduardo Augusto Gouveia dos Santos <cst...@ibm.net> writes:
>Dear Gardner,
>I agree with almost everything you state but the idea of MWAPI's death.
>Micronetic's Workstation product is based on it and all the customers I
>have which run GUIs use MWAPI as the underlying API.
>MSM-PC already had a front-end with VERY GOOD performance to run what we
>had on that moment: CHUI applications.
[etc.]
I want to clarify something ....
I have been in the M community for a while now. I am on the executive
board of the New England Users Group. I helped out with the MTA meeting
this year, and I work for a company that has close ties to a specific
vendor.
When I make comments I try very hard to be even handed. I rarely use a
vendors name (for good or bad comments) and try not to appear in one camp
or another. As a matter of point, I value and need all the vendors that
are out there.
So, please read carefully what I said. I have been stung in the past by
misinterpretations and floow-up comments that infer I made a point I did
not. I maintain that one vendor has worked hard to embrace MWAPI, others
(in MY opinion) have made business decisions not too. That is thier
perogative. They, as we all, have finite resources and have to plan as we
feel is best. This is a small slice of a large pie. I tried to make
comments about this without 'personalizing' it. I am not about to bash any
of my friends. And I believe my friends and peers at these companies
realize that constructive criticism is healthy.
Sorry I used your post as a sounding board, but I felt the need to
clarify. I don't need to fight unintentioned word-wars.
Thanx, and great comments there.
Greg Kreis
Arthur B. Smith wrote:
> This in turn leads to "macroefficiency" at the expense of the
> "microefficiency", or at least, that's my guess.
Right! The lack of 'layers' and having to go around the world to do
something pays off. BUT this directness is also what caused us to be
alienated from an 'open' world - frought with all its complexity and
inefficiencies.
Greg Kreis
Paul Perrin wrote:
> I think the flaw with this is the position of M within it. Java already works
> as a client language and as a server (cgi or api) language -- where does M fit
> in?
I believe M could serve well in a Distributed Object world. When we
wrap M apps up in objects, then who cares what combination of logic and
data produced the result? If M gets it done faster and cheaper...
GREAT.
> I have yet to see a genuine Java application. The specification looks good,
> talk is common, but where is all the Java shareware on the internet? Would any
> one here have a clue how to install a java app on their computer?
Corel has created an office suite in Java. Penumbra has created a very
advanced IDE entirely in Java. Take a look.
Imagine saying to someone that you felt M would not catch on only two
years after it was invented because of lack of apps? It needs time to
mature. It needs to settle in, stop changing so rapidly and people need
to trust it. How long has C++ been around? For all the C++ claims to
be a popular language, it is not nearly as commonly found as C, from
what I have been told.
> If java is so great for development, then where is it?? I understand that some
> banks are using it seriously, but then a fair number of banks used (still use?)
> NeXT hardware! Niche, niche, niche.
Can't the same argument be made about M? Don't you believe M to be
great for development?
> If the Java hype can be maintained for long enough then it will eventually get
> a solid foot hold, but it has *NOT* taken the WWW by storm...
Java has not taken the Internet by store for a couple of reasons, IMHO.
Need for mature IDEs to make it more visual (these are emerging as I
type)
Not enough bandwidth
Learning curve
These barriers are the very reason for the explosion of HTML. Pent up
demand for shared data has put up with the limitations of HTTP and
HTML. I suspect Java will eventually be able to fill the needs of HTML
and C/S type GUIs. Who wants to have to decide what platform before you
start something? Things seldom go as planned. We need to be able to
start quickly but have enough robustness to grow, rather than having to
tear down and start again with another tool.
> And now that MS
> have decided to reject part of the Java standard, and bastardise the rest of
> it, then it may well not be portable anyway, there will be Java and MSJava --
> and if you were going to use MSJava, then you may as well go activex in the
> first place.
No argument about using pure Java or dumping it for MS only stuff.
IMHO, the spirit of Java is smothered under the proprietary blanket of
MS (or any other single vendor seeking to dominate a language).
> Me? In the past I've done raw windows API from C and pretty/easy windows from
> Delphi, but now I've learnt perl and the basics of java (nothing revolutionary,
> just a neat-enough repackaging of various programming language concepts).
Isn't that often the essence of a new invention that succeeds? A
repackaging of principles that combine, with serendipitous timing, to
flourish.
> But, until something comes along that can come somewhere close to DTM
> (development speed, execution speed, database speed), then DTM is what I'll
> use by preference myself. For clients I'll write in whatever they fancy.
I agree with this statement TODAY. I have no experience with a product
that can beat M for 'hauling the mail'. BUT, how long will that last?
My advice to all of us M advocates is to always be learning - I unwisely
super-glued my saddle to two technologies that were superior in my
opinion - Macintosh and M. This time around, my saddle is
removable.... ;)
If I was involved in a project shooting for deployment in the next 18-24
months, I would be looking at some way of using M to provide a robust
object database to Java servers and clients. Actually, I would be
interested in seeing how M compares to the maturing Object databases on
the market. Hmm... it would be interesting to see how to serve objects
and SQL from the same database... ;)
I'll use M when it makes the most sense... but not to the exclusion of
other products. That sounds like what you are saying, right? For those
who know me, this has been a radical change in my thinking (I know... I
am late to the party... ;).
Patricia M. Riggie
At 02:41 PM 6/22/97 -0400, you wrote:
>At 04:15 PM 6/18/97 -0400, Eduardo Augusto wrote:
>
>
>That is a reasonable approach - and have been used with great success
>by many users of M technology - with all M implementations - but that
>approach has a lot of serious drawbacks - rather fat clients, being tied
>to MS-Windows, installation hell (.dll's, .vbx's, and .ocx's, and having
>the get the right versions of those .dll's and controls), things not working
>portably or being available even across the Microsoft platforms (ever tried
>to use a TrueGrid control, or a product that depended on one - on a non
>Intel Windows NT platform???).
>While this may have been the best approach a few years ago - I really don't
>think it is any more.
Your drawbacks were some of the reasons why we chose to not go that route.
Instead we have taken another approach using Perl/CGI scripts as our
two-way conversation between HTMl and M. The M applications were modified
to allow for both character and GUI interfaces to the data. The solution
required only two new M routines: one to process parameters passed to MSM,
the other to open file, write some html code to the file and then close the
file. One Perl script is used to process the search requests.
>
>>If the question is access by anybody in the internet I would try an HTML
>>approach. I have the idea (anybody have comments on it??) that Java
>>would be 1)not a 'de facto' standard 2)not supported by every browser
>>3)not as flexible as a true GUI approach.
>
>I think you are wrong here on all points. I would recommend an approach
>using HTML/Java/JavaScript with an M backend over any other approach.
>With M/Weblink you can use practically any M vendor, and practically any
>hardware platform for the M host (the M host and the Web host can be the
>same machine on many platforms - such as Win95, WinNT, and various Unixes).
>
>1) Java is already much more of a 'de facto' standard than MWAPI ever was.
>2) What browser are you using that doesn't support Java?
> NetScape, MicroSoft, Sun, IBM, Oracle, etc. are all crowing about their
> Java support...
>3) What do you call a "true GUI approach"? What makes one GUI "truer" than
> another? What lack of flexibility do you see with Java? You can do
> anything from Java that you can do from C if you need to (just add some
> native classes, or use MicroSoft's JDirect to gain access to all Win32
> APIs - although I'd never recommend it)
>
>Java already has a great deal of support for international applications -
>full Unicode support (which makes it tie in very well with the upcoming
>Unicode release from InterSystems), and later this year a much better API
>for doing GUI programming will be out (based in part on Netscape's IFC
>- Internet Foundation Classes) - that will still be just as portable as
>Java is now.
One has to keep in mind that everyone does enable Java and Javascript on
their browser. I found that out when working on the publications form for
MTA.
Pat Riggie
WV CONSULT - A Statewide Health Information Network located at
http://consult.hsc.wvu.edu
riggie....@consult.hsc.wvu.edu
http://www.mtechnology.org <-- Dedicated to promoting M Technology
http://www.hardhats.org <-- Dedicated to supporting VISTA/DHCP Users
Eduardo Augusto Gouveia dos Santos
Gardner S Trask wrote:
> I have been in the M community for a while now.
>
> [ETC]
Yes, it was very nice of you to explain it in such a detailed way.
Thanks a lot.
Roger Cope
> Newsgroups: comp.lang.mumps
> From: John Murray <Joh...@uk.micronetics.com>
> Subject: Re: GUI and MUMPS
> Date: Mon, 23 Jun 1997 10:45:00 -0400
>
> Scott P Jones wrote:
>
> >While M itself is portable, using MWAPI isn't really very portable.
> >For many reasons, it hasn't gotten very broad support from
> implementors.
> >(I could go into the problems with its design, etc. that helped to
> cause
> >this situation - but I'll leave that be right now).
>
> And other c.l.m readers might have input too.
>
> John Murray
> Software Engineer
> Micronetics Europe Ltd
John,
I have to say straight out that I haven't used MWAPI, only read about
it, and my impression is that it seemed to be hard work. The effort put
in to making it cross platform and 'formalised' in structure seemed to
have no advantages to developers. I guess that Micronetics have now
hidden most of that 'API style' syntax by providing GUI generators and
toolkits.
For the past couple of years I've been writing GUI interfaces to M
systems using VB and Delphi (the latter being far better). Apart from
anything else, my employers (for whom M is a sideshow amongst all the
Oracle) saw VB and Delphi investment in a far better light than paying
good money to tie themselves further into M.
Ironically, the success of my Delphi interfaces (seriously fast,
genuine thin client, with state of the art custom controls adding
'glitz') has persuaded my employers to make significant investment in
the M database back ends of these systems.
Now, Micronetics MWAPI based tools may be equally as good as using
Delphi (though I imagine the range of non standard interface widgets is
more limited!) but I doubt I could have got the time and funding
necessary to have invested in them and, more importantly to myself, I
now have very marketable skills that I didn't have as a pure Mumpster.
Conversely, my employers are pleased to know that 30% of their M Tech
systems are actually written in VB or Delphi which increases their
chances of being able to support them in the future.
Roger Cope
Ed de Moel
Scott P. Jones wrote:
>
> [ ... ] I don't think
> there was very much implementor involvement in the design [ ... ]
>
A quick scan of the documents that led to the establishment
of the MWAPI standard reveals that the leaders in this effort
were two "little known" companies from Massachusetts.
Would there be anyone from Digital Equipment Corporation
or InterSystems who would like to comment on this?
Ed de Moel
fabn...@gmail.com
> Has someone had experience with the diffrent ways a GUI front end
> can be added to MUMPS. More specifically what the major differences
> between ISM implementaion and MSM. Which one of the two runs faster?
> Are there any other options available that are used alot in the field
I recognize that to integrate such a portable GUI toolkit directly into MUMPS will require significant design and development, and may require enhancing or adding to MUMPS a new event mechanism, and possibly other features.
Kirt
You should look at EWD, Enterprise Web Development - now as EWD.JS, incidentally a free, open source stack with GTM MUMPS.
It allows easy use of most Javascript based Frameworks- an awesome collection of capabilities on the front end, the User Interface.
See Rob Tweeds Blog-
http://robtweed.wordpress.com/
and
https://groups.google.com/d/forum/enterprise-web-developer-community
The Browser is the GUI. You can clearly run locally, using localhost even on a Linux-device. The Browser standardizes across "all" hardware and devices and OS variants and versions. Where that fails, the Frameworks like JQuery and bootstrap hide the inconsistencies across a huge range of sizes no mortal programmer could be expected to cope with alone.
Interesting how this conversation straddles seventeen years or so, but popped up on my screen somehow and has been a topic of interest to me for longer than that.
Kirt Walker
.
rtweed
>
> You should look at EWD, Enterprise Web Development - now as EWD.JS, incidentally a free, open source stack with GTM MUMPS.
>
Rob
Jerry Rice
Jerry