Web based IDE

[Alex]

Hi all,

I can't get my head round having to have a windows os available in
order to run the EsiObjects IDE.
I understand the Java IDE hit the end-of-line some time ago.

I got involved with a technology evaluation pilot recently that
involved looking at desktop application replacements.

A couple of technologies that came out on top were Silverlight 2.0 and
Google Web Toolkit.

Silverlight is very good for many things but unless you have specific
requirement for vector graphics or C# then GWT provides some ground
breaking possibilities.

Firstly you write and debug your application in Java.
When you are happy with it, the GWT generator transforms the Java
client into a JavaScript client.

This JavaScript client will run on any web browser without any
plugins. It has no deployment footprint.
The whole client is a static javascript file served from Apache.

Writing type safe event code in Java is a huge improvement from
messing around with hand coding javascript.

Also the GWT generator is aware of memory leak issues with specific
JavaScript engines and caters for the idiosyncrasies of comparison and
math operations in JavaScript.

I was thinking that a web based EO client using GWT would negate the
need for new developers to download a virtual appliance as it would
work just as well for hosted GT.M environments.

The license is Apache 2.0.

HTH

[ferret1964]

All,

I would not say that the Java IDE has hit the end of line yet - It's
actually fairly high on my personal work queue. I'm more then willing
to provide back end services to any web front end anyone may want.

Jerry

[Terry L. Wiechmann]

Ahhh! A subject close to my heart!

Just to set the foundation for this discussion let me outline a little
history:

* The original IDE was built on DTM's GUI Package - we know where
that went...
* Next IDE was built on MWAPI - we know where that went...
* Frustrated with these approaches, we bit the bullet and went with
C++ and MFC. This was when Java really did mean coffee. ;-)
* While NetBeans was being developed, two attempts were made to
implement a client using it
(https://sourceforge.net/project/showfiles.php?group_id=35585&package_id=121148).
So many changes were being made to NB at the time, it was abandoned.
* A really good programmer working on an EO project, took it upon
himself to start a C based IDE using Red Hat V9
(https://sourceforge.net/projects/geode/https://sourceforge.net/projects/geode/).
He moved on and it was left incomplete. At lease it has a cool
name. 8-)
* The current C++/MFC based IDE continued to evolve under Jerry
Goodnough's direction.

We really need a new, portable IDE.

OK, it's time I enter the confessional... When we created EO, I decided
to present it as a new direction - so we made the IDE OO specific and
pretty much avoided building on M first. That was a dumb move! We should
have built a good M IDE and added the OO stuff to that. If we do this, I
really would like to learn from my mistakes and first build a good M IDE
(I'm assuming Atmus has that in their plans) and then extend it with the
OO functionality found in the current EO IDE.

All views welcome...

Terry

[Alex]

Netbeans has been my preferred IDE for java for a long time. Just
finished a project using it. :)
They had some interesting changes for project layouts that caused some
issues I seem to remember.
I never got into using Netbeans platform proper apart from their
convenient layout managers.

However as Oracle has bought Sun I can't really see any reason to for
the sponsorship of Netbeans IDE bundled with GlassFish server anymore.
I'm sure they'll be pushing for JDeveloper bundled with WebLogic
server instead.
GWT has community support for implementation on both Netbeans and
Eclipse though Eclipse is the recommended development platform to use.

With regard to the backend services for a new web front end, GWT has 3
service bindings:
* GWT-RPC for Java servers
* XML-RPC over HTTP
* JSON over HTTP

I assume a simple XML-RPC endpoint could be a CGI initiated mumps
controller routine. Is there a well defined interface that separates
the client-server implementation? Can server methods be mapped to XML
messages for XML-RPC relatively easily? Maybe you already have a web
service defined for this?

What capabilities do you need of a general Mumps IDE?:
* Syntax highlighting
* Debugging capability
* Compile
* Search and replace

I presume the above is very specific to m platform, so does GT.M have
priority or does this need to work with Cache too?

[Terry L. Wiechmann]

Comments inserted below. Most of this overlaps into Jerry's knowledge domain.

Alex wrote:
> Netbeans has been my preferred IDE for java for a long time. Just
> finished a project using it. :)
> They had some interesting changes for project layouts that caused some
> issues I seem to remember.
> I never got into using Netbeans platform proper apart from their
> convenient layout managers.
>
> However as Oracle has bought Sun I can't really see any reason to for
> the sponsorship of Netbeans IDE bundled with GlassFish server anymore.
> I'm sure they'll be pushing for JDeveloper bundled with WebLogic
> server instead.
> GWT has community support for implementation on both Netbeans and
> Eclipse though Eclipse is the recommended development platform to use

> With regard to the backend services for a new web front end, GWT has 3
> service bindings:
> * GWT-RPC for Java servers
> * XML-RPC over HTTP
> * JSON over HTTP
>
> I assume a simple XML-RPC endpoint could be a CGI initiated mumps
> controller routine. Is there a well defined interface that separates
> the client-server implementation? Can server methods be mapped to XML
> messages for XML-RPC relatively easily? Maybe you already have a web
> service defined for this?
>
> What capabilities do you need of a general Mumps IDE?:
> * Syntax highlighting
> * Debugging capability
> * Compile
> * Search and replace
>
>

Yes, all of the above. For syntax highlighting (and other applications),
I proposed an ANTLR definition of the M language and EO extensions (shot down). I got the 95
standard to a point and then ran into a wall - language definitions are not my
forte. There are other reasons for having this... another discussion.

> I presume the above is very specific to m platform, so does GT.M have
> priority or does this need to work with Cache too?
>

I'm opposed to focusing on just one M implementation. Our philosophy has always been to support all M systems.
It's more work but it addresses a wider audience (ignoring the fact that Cache has it's own OO implementation).
However, having said that, a FOSS stack with GT.M is the priority in my view.

> >
>
>

[Terry L. Wiechmann]

Comments inserted below. Most of this overlaps into Jerry's knowledge domain.


Alex wrote:

> Netbeans has been my preferred IDE for java for a long time. Just
> finished a project using it. :)
> They had some interesting changes for project layouts that caused some
> issues I seem to remember.
> I never got into using Netbeans platform proper apart from their
> convenient layout managers.
>
> However as Oracle has bought Sun I can't really see any reason to for
> the sponsorship of Netbeans IDE bundled with GlassFish server anymore.
> I'm sure they'll be pushing for JDeveloper bundled with WebLogic
> server instead.
> GWT has community support for implementation on both Netbeans and
> Eclipse though Eclipse is the recommended development platform to use

> With regard to the backend services for a new web front end, GWT has 3
> service bindings:
> * GWT-RPC for Java servers
> * XML-RPC over HTTP
> * JSON over HTTP
>
> I assume a simple XML-RPC endpoint could be a CGI initiated mumps
> controller routine. Is there a well defined interface that separates
> the client-server implementation? Can server methods be mapped to XML
> messages for XML-RPC relatively easily? Maybe you already have a web
> service defined for this?
>
> What capabilities do you need of a general Mumps IDE?:
> * Syntax highlighting
> * Debugging capability
> * Compile
> * Search and replace
>
>

Yes, all of the above. For syntax highlighting (and other applications),
I proposed an ANTLR definition of the M language and EO extensions (shot down). I got the 95
standard to a point and then ran into a wall - language definitions are not my
forte. There are other reasons for having this... another discussion.

> I presume the above is very specific to m platform, so does GT.M have
> priority or does this need to work with Cache too?
>

[Alex]

Many IDEs contain some form of extensibility either by providing
attaching of external tools or via marcos and scripting.

Consider the Cache IDE has the ability to add custom items to menus.
These items can launch CSP tools. These tools can return content back
to the current open document for example to insert the html colour of
a element or generate whole classes.

This kind of extensibility would allow for example the Atmus
management portal tools eg:
* to configure global mappings
* start or stop services,all without leaving the EO IDE.

Perhaps it would be useful for the EO IDE to be able to re-brand the
color and styling of web based tools. ie: have well defined CSS
templates that EO IDE can override to give the impression of
continuity between the EO IDE and external web based tools.

[K.S. Bhaskar]

Since PIP already comes with two IDEs (one of which is browser based and
the other - more capable - Eclipse based), it would make sense to build
on what is already available and already know to work with GT.M, and
which could be extended to other MUMPSen because GT.M is "just MUMPS".

Regards
-- Bhaskar

_____________

The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________

[Terry]

I installed PIP and looked at it before you had the conference in
Melvern. These were the problems I had with it (strictly from an
EsiObjects IDE perspective):

- It seemed to still have lots of Profile specific stuff in it which
would have to be stripped out.
- It had the Object Scripting which would have to be stripped out
since it would be confusing and redundant.

Bottom line is it seemed that the only thing we needed was the MUMPS
editor (no small thing). I was left with the impression (right or
wrong) that it would be easier to start from scratch?

Comments?

[K.S. Bhaskar]

On 05/30/2009 10:41 AM, Terry wrote:
>
> I installed PIP and looked at it before you had the conference in
> Melvern. These were the problems I had with it (strictly from an
> EsiObjects IDE perspective):
>
> - It seemed to still have lots of Profile specific stuff in it which
> would have to be stripped out.
> - It had the Object Scripting which would have to be stripped out
> since it would be confusing and redundant.
>
> Bottom line is it seemed that the only thing we needed was the MUMPS
> editor (no small thing). I was left with the impression (right or
> wrong) that it would be easier to start from scratch?
>
> Comments?

[KSB] The first release of PIP didn't have a clean separation of the
Profile infrastructure from the financial applications. But the next
release (I just need to find the time to clean up the packaging) is much
cleaner and smaller.

Note that the IDEs are all completely outside the GT.M environment.
Look for them in the Tomcat environment.

Regards
-- Bhaskar