Thanks Sean!

No. It was build over REST indeed while WebTerminal, from very first its version used WebSockets. However, the same interface can be implemented over WebSockets :) In WebTerminal, there is a simple JSON messaging, there is no need to add more tools there I think.

And here is the link to our project :)

Missed this. I have never seen WS client implementations on COS neither.

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".

Sean,

As for Caché web based IDE you may be interested in my Caché Visual Editor project. It allows to perform almost any edits over Caché ObjectScript classes. If you will be interested, we can continue working on this project.

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:

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!