Thanks Evgeny. I don't have a demo but you can find all the sufficient documentation and a smart contracts address within the link provided. We have a working smart contract and you can see some historical billing transactions there.
Hello Matthew! Thank you for your feedback.
Indeed good point. One idea that comes to my mind for this case is to improve the import script to file the list of classes which were ever imported and those which are used now. By using this list the import script can resolve which classes to delete and which to keep. However, deleting classes can always introduce unwanted side effects, but in terms of a project this should be consistent.
Great news, congratulations!
P.S. Special thanks to Evgeny for pointing out to exactly WebTerminal's analytics class :)
Exactly not for installing purposes, you're right, I agree. But what do you think about the WebTerminal case in particular?
1. It's already developed and bound to projections: installation, its own update mechanism, etc.
2. It's also shipped outside of ZPM
3. It would work as usual if only ZPM supported projections
I see you're pointing out to "It might need to support Projections eventually because as you said it's a part of language" - that's what mostly my point is about. Why not just to allow them.
Thanks! Exactly, I completely agree about simplicity, transparency, and installation standard. But see my answer to Sergey's answer - what to do with WebTerminal in particular?
1. Why would I need to rewrite the update mechanism I developed years ago (for example)?
2. Why would I need to maintain 2 code bases for ZPM & regular installations (or automate it in a quite crazy way, or just drop self-update feature when ZPM is detected)
3. Why all these changes to the source code are needed, after all, if it "just works" normally without ZPM complications (which is how the ObjectScript works)
I think this leads to either "make a package ZPM-compatible" or "make ZPM ObjectScript-compatible" discussion, isn't it?
True points. For sure, developers can customize it. I can do another version of WebTerminal specifically for ZPM, but it will involve additional coding and support:
1. A need to change how the self-update mechanism works or shut it down completely. Right now, the user gets a message on the UI, suggesting to update WebTerminal to the latest version. There's quite a lot of things happen under the hood.
2. Thus, create an additional pipeline (or split the codebase) for 2 WebTerminal versions: ZPM's one and a regular one with all the tests and so on.
I am wondering is it worth doing so in WebTerminal's perspective, or is it better to make WebTerminal a kind of an exception for ZPM. Because, still, inserting a couple of if (isZPMInstalled) { ... } else { ... } conditions to WebTerminal (even on front-end side) looks as anti-pattern to me.
Thanks! Considering the points others mention, I agree that projections should not be the way to install things but rather the acceptable exception as for WebTerminal and other complex packages.
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.
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.
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):
Hello! Thank you for posting the question.
Thanks to @Francisco Lopez 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.
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!
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!
Hi Robert! WebTerminal's developer here.
In WebTerminal, there are somecoreblocker 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.
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!
Also check out ObjectScript Visual Editor - from what I remember it runs on IRIS (however last major versions were not tested).
Hello! Thanks for the question. This is a typical question on some machines or with some networking software. Try looking through the issues to find the answer. In my experience, as well as my colleagues experience we never encountered these problems.