Hi Robert! WebTerminal's developer here.

In WebTerminal, there are some core blocker issues we didn't find a way to fix. They are not allowing to support some "traditional" debugging commands and some of those commands you've mentioned. The core problems are described in the issues, take a look. Mainly, it is because WebTerminal is implemented on top of WebSockets and uses "xecute" under the hood. I was asking about re-implementing the WebTerminal's core over telnet to overcome these issues, as then the standard terminal (telnet?) device will be used, eliminating these existing issues. So far, we just need to find an approach to execute arbitrary code in IRIS/Cache using the terminal device, which was not found yet.

Hello Arto!

Thank you for letting us know. I don’t think that WebTerminal could cause any damage to Studio/debugger. At least, you can try to completely remove WebTerminal by deleting WebTerminal classes (right click in Studio or select classes in the Management Portal -> Delete) and test it again. But anyway it has nothing in common with studio nor debugger.

Apart from that, what are you trying to debug? It might be you just misusing it, but I believe you did it before successfully.

Hope this helps!

Hello! Thank you for posting the question.

Thanks to @Francisco.López and @Eduard Lebedyuk for pointing out to the right place.

Indeed, there was a little mess with links and downloads: the information was spread across 3 repositories on GitHub. I moved all the stuff to intersystems-community repository, as well as added releases there. This repository can now be treated as the main repository of the project. Also, there is the releases page with the latest XMLs you can download for installing ObjectScript Visual Editor. This page is also linked in Open Exchange and the readme file.

Would love to hear your feedback! Thank you!

Nikita, the developer of this app.

Joining this question.

It would also be nice if someone could describe how to catch and process I/O at this point. Ideally I am looking for something like:

set pseudocode = ##class(Any.Util).Execute("cmd") // let's say on Windows
do pseudocode.Write("ipconfig")
// loop may go here
set data = pseudocode.Read()
// loop may close here
// ... and the data is the stdout of the process!



Hello Yuval!

To install WebTerminal 2.0.0-beta.8 on Caché 2013.1,

1. Go to WebTerminal Downloads and download the version 2.0.0-beta.8, which is the XML file. This page also has some instructions about how to set it up.

2. Using Studio or whatever you like, import this XML file into the %SYS namespace and compile all imported classes / CSP pages. If you have the "access error" while importing classes, then you need to temporarily enable write access to CACHELIB database, see here how.

3. Open <host>:<port>/csp/sys/webterminal/index.CSP page in the browser.

The dark part of using v2 is that this version of WebTerminal is very old and have a lot of things that were improved in 2 major releases v3 and v4. Furthermore, despite of it was tested on 2013.1 (some particular version) it may not work there now, as it seems like some changes in WebSockets appeared in InterSystems WebSockets engine, and probably 2013.1 may have a minor release adding them. But anyway, you can try.

Versions 3 and 4 of WebTerminal is not compatible with 2013.1 for the only reason — they use %CSP.REST classes. You can try to port WebTerminal resources onto CSP, but this may not be trivial.

Let me know if this helps! I will add this instructions to the WebTerminal downloads page. Thanks!

Hello Sean!

I am a developer of WebTerminal project, where I was playing around WebSockets in Caché every day. Also I am experienced in CSP / REST as I use them often, and NodeJS/JS are my daily drivers.

Regarding to WebSocket and CSP/REST in Caché I need to say that it is probably about of how InterSystems designed their tech. 1 dedicated process corresponds to 1 user, and I have no idea about doing something here, because historically (and actually) Caché takes account on a number of clients this way and performs licensing, so anything that interrupts to this mechanism is probably not available for the hi-level programming. But actually, each Caché process takes around 3MB of memory, so it is not too much losses here.

For Caché long-polling it's a normal practice to hang the Caché process for a while. Because one process is dedicated for each client, it won't affect other clients connected, and won't consume processor resources while hanging. I cannot tell more from the practical point of view here, as I used WebSocket whenever possible, which... Acts pretty much the same way. Also I haven't ever heard of firewall blocking WebSockets.

Yes, Facebook, Twitter and other big internet guys are using long polling, just because there is no reason to change their communications to WebSocket protocol, long-polling works well, and actually there is only one reason not to do it: around 6% of clients still not adopted to use them (IE9, Android 4.3 and lower, see here).

As for 2017, I will recommend using WebSockets wherever possible. If your clients may use outdated tech, which actually matters for Facebook, then I recommend just going with http long or short polling, depending on your application needs, without any WebSockets and http fallbacks.

But I cannot say that I am happy with the way how WebSockets implemented in Caché. For a single-client applications it's okay, but however implementing the clean pub-sub over WebSockets in Caché needs to deal with globals (which sometimes syncs with disk) or use interprocess communication (which is not effective sending big chunks of data), which creates additional hangs or lacks in flexibility.

To summarize. If ~5% of outdated clients is a big deal for you, I would recommend using short-polling for some of the applications, which have no need to deliver data simultaneously, and long-polling for primarily everything, without overloading the communication with WebSocket.