Windows-only? Hmm. So I am throwing the idea about telnet out. Thanks!

Maybe there are other ways to enter the terminal "programmatically" for all platforms? What else I have read from the internet is csession thing. Maybe we can run this terminal session from COS and somehow take control over its I/O... What do you think?

Hi Nigel!

I have been using %CSP.WebSocket class for my WebTerminal project. All you need to handle WebSocket connections is in this class. By mixing globals and/or interprocess communication you can achieve pretty much any result you need. There are plenty of resources in the Internet to get started with InterSystems WebSockets, but if you have any particular questions (which is not obvious from the post content), feel free to ask.

P.S. Oops, posted answer instead of comment.

Hi Evgeny!

Could you please create an issue on GitHub describing:

1. Did it happen before/with prevoius versions, symptoms;

2. Closing status and overal pooling time of the closing socket;

3. Which type of connection and Caché you use (https?);

4. The WebSockets frames dump will also be extremely useful (take a screenshot from Developer Tools -> Network -> Select "WS" and click on WebSockets channel -> Click "Frames".

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.

Cool article Edward! Nevertheless I have a little note here.

According to my experience working on a huge code base, logging with macros may turn to a big pain as soon as you decide to change (add, etc) arguments to your macro, or in other words, change the macro code.

We had an application full of logging macros with something like you mentioned:

#define LogFatal(%message)        $$$LogEvent("FATAL", %message)

And at some point the logging mechanism became working improperly and we needed to change it (yuh, this logger used TCP connections and some other stuff to behave like "universal" logger in the application). But simply changing the macros code was not the case: we needed to recompile everything (as macros is compile-time code generator)! Every class on live system which used this macro. This was not successful (even on test environment) for the reasons I don't remember to be honest. What we did instead is... We spent a few days replacing all the macro code to simple class method calls like do ##class(Logger.Log).Warn(whatever). With this approach, when you change the Warn method and recompile, everything is applied immediately.

The pros I see for using macros to class methods is the thing that you can type around 15 less characters for logging, and optionally have some compile-time expressions about the logged class using macros. But the cons here is using macros itself... I believe the similar approach can be done with class methods and with the help of $stack variable.

Any comments on this? Thanks!

Timur,

The package manager is the most-wanted tool for sure, thanks for sharing the ideas. I want to add some mine ones, mostly from my long experience of using npm.

My projects are all shipped as XMLs (ClassExplorer, WebTerminal, VisualEditor, etc), so the container for the package should be XML. At least, that's the easiest solution what we have for now.

Dependencies. I think all the dependencies for Caché should be strictly = to some package version, as my experience says me that if you miss 4 month of development, you may miss deprecated methods you are using in a package that was deleted for the latest version of the package.

The key breakpoint here is, for example, if the package A uses package's C version 0.0.1, and package B uses package's C version 0.1.0 (which behaves differently and is not back-and-forth compatible!), how do we resolve the:

1. ClassName

2. ClassVersion to use

And I bet there is no "perfect" solution here... It sounds like we should always develop at least back-compatible package versions.

Tool.

I have tried installing CPM. It worked! But resulted with some errors during the import:

Загрузка файла Z:\temp\CPM\t\depends\C\manifest.xml как xml

ERROR #6301 Строка: 1 Смещение: 11 no declaration found for element 'Manifest' while processing Z:\temp\CPM\t\depends\C\manifest.xml at line 1 offset 11

ERROR #6301 Строка: 1 Смещение: 11 Непохоже на файл экспорта Cache, невозможно импортировать.

 

Then I tried to install WebTerminal from the CPM shell by doing cpm install intersystems-ru~webterminal from WebTerminal. It ended with successful class compilation and then neither WebTerminal or CPM were working (do ^CPM just says "building the indices for the first time" and exits). Other packages were also installed with some errors regarding to their class compilation issues. I know that this is a very-very early version, and I would be happy once this will get resolved.

Partly-installed packages doesn't seem to include metadata class. Does it supposed to be?

Thanks for development, keep going!

Cache for Windows (x86-64) 2017.2 (Build 543U) Fri Nov 4 2016 01:11:15 EDT

Steffen,

All the software in the world is not protected against human mistakes... Especially if it's the user interfacing software, Mac, Windows, doesn't matter: they all have bugs.

Once you find thing that brakes something, please, do not complain about the open-source packages like here: just submit the bug report to the project.  If the bug is critical like this one, it will be fixed in days, if not in hours.

The reason was just in /ClassExplorer web app setup: it was set up as namespace default application by default, and the URL SOAP Wizard used in studio were incorrect.

The fixed version of ClassExplorer is here, please update it or just change "Namespace Default" to false in /ClassExplorer web application.

Thanks!

Of course, Javier! Thank you for your interest and attention on this project.

If you application is open-sourced (or if you can share it with me), then it would be easier for me to figure out which escape sequences are missing. If not, you would need to find out what happens and which parts of your application is not supported by WebTerminal.

Regarding to F1-F12 keys support, I already have the way of implementing it, so please create the issue here to track the progress. For other things, like "graphic characters are not displayed", "it doesn't allow to draw boxes or lines" I need more detailed technical description, including possible code which doesn't work in WebTerminal, but does work in Caché TERM.

Feel free to submit your requests to our GitHub project issue tracker, this helps to create an even better project!

Thanks!