Thanks Peter and Dmitry.

It looks like WebTerminal is just missing a backspace interpretation, client-side.

I can fix this problem once I have some free time, should be quick.

Thanks for reporting!

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!

It's Nikita, the creator of WebTerminal.

There is no such thing implemented in WebTerminal. Because, still, all the commands are executed via xecute Cache command under the hood in a dedicated process.

However, if you really need this to be implemented - feel free to create an issue here.

Hope this helps!

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.

Hi Mike!

When WebTerminal says “See You!”, it means that the server process normally exited. Which means that something prevents WebTerminal from running normally on the server or terminates WebSocket connection.

Try to delete WebTerminal classes and install it again into different clear namespace (like USER). Does it help?

Maybe you just need to update Atelier? I checked mine, and it has everything to export CSP files, both from context menu and project export menu (right click on project -> Export):

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:

 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.