Thanks @John Murray for all your expert contributions to the InterSystems/VS Code ecosystem! 

For Chrome, if you know how to modify HTTP headers directly, this one seems reliable and popular (but I haven't tried it): https://chromewebstore.google.com/detail/requestly-intercept-modif/mdnle...

So now the problem isn't installing the Python library, but connecting to IRIS, correct? If you're using the above code on both servers, is the connection info the same on both servers?

Here's the link to InterSystems Components. It requires a login. 

Congratulations!

Great suggestions here. This reminds me the folks at myCTS once again showed off webHERALD at Global Summit this year. Another option in this space. @Armin Forstner could say more. 

Sounds very promising and a big time saver!

As @Brett Saviano says, if you simply need to work with JSON data, use dynamic objects. If your question is really about the future of data-centric web development with InterSystems, let me step back and offer a higher level viewpoint. %ZEN has been deprecated because it requires some browser features that have been deprecated and may go away at any time. Therefore, we cannot continue to recommend usage to our developers when browsers could break Zen applications and any moment. The DeepSee v3 REST API uses %ZEN classes because it has not been rewritten since the deprecation. 

Zen was developed a long time ago, and many great application development frameworks have gained popularity since then. There are examples of Angular, React, Django and more recently, Streamlit being used in conjunction with IRIS.

There doesn't seem to be a strong desire for offering a proprietary web development framework that could never achieve feature parity with those mass market offerings, and could only beat them in providing faster, more efficient access to the data layer. But I'd love to hear more voices from the community on this topic. 

Thanks for providing this service to our community. As mentioned in the 2024.1 release notes, Studio will no longer be installed by default in 2024.2 and later, so now is a great time to fully migrate your staff and processes to VS Code. 

Sounds really cool. Looking forward to the progress!

Is a recording available, @Olga Zavrazhnova?

@Michael Davidovich if you're using IRIS on Docker and client-side editing, there is no need for the local source code folder to be mounted on the Docker container. ObjectScript is uploaded to the server using the network connection just as if IRIS was on another machine.

@Dmitry Maslennikov is right. Package information is not present in the UDL format so it doesn't make sense to support it in VS Code. Therefore, Studio's deprecation also deprecates this feature.   

That's great news @John Murray! Thanks for helping make this happen.

Great discussion topic!

As you say, ISC will not take over orphaned packages. Not only because of the time commitment, but also because the spirit of OpenExchange is to promote developer-to-developer initiatives. If a package has fallen dormant and no one else wants to fork it and maintain it, then that's a signal it isn't worth maintaining. The open source equivalent of Darwin's "survival of the fittest". 

For me the big question is, how to make these orphans disappear into the darker recesses of OpenExchange so that a casual user doesn't find them easily, have a bad experience, and get a bad impression of OpenExchange in general. What if we had some algorithm for defining "orphan", such as, a repo that has not been modified in over 24 months, or has not been modified in over 6 months and also has outstanding pull requests with no comments on them. Using this algorithm we could annotate every OE entry with it's "active" state and filter out orphans from the site by default, but allow users to see orphans by explicitly turning off that filter.

Thanks for sharing your experience.