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.

Great discussion topic, @Dmitry Maslennikov. Having the IRIS Data Platform play a role in all kinds of data warehouse/lake architectures is certainly important. Especially since these architectures have been evolving recently to take advantage of the convergence of systems of record and systems of reference -- i.e. transactional and analytical databases. In short, one can easily make a strong argument that the IRIS Data Platform can be the foundation for most operations on data -- transactions, analytics and machine learning. On top of that, I see a strong opportunity for our developer community to create tools that offer better DataOps capabilities, like orchestrating data transformations with data pipelines, creating data catalogs, and augmenting all these with machine learning tools to automate much of this data engineering work.

Hello @Humza Arshad. Thanks for your question! 

Since IRIS 2022.2, you can use JWT authentication to provide a RESTful way of logging in and maintaining that session, which is in line with how many frontend frameworks like to work. The documentation can be found on the JSON Web Token (JWT) Authentication page.

To take advantage of this, you will need to do the following:

1. Use Unauthenticated access on the web application that serves the UI app
2. Enable JWT authentication on the web application that handles REST requests
3. Set UseSession = 0 on the REST handler class for the web application that handles REST requests
4. Create your own custom login page in the front end. Upon login, this page should submit a payload containing { user: …, password: … } to the /login endpoint as explained in the documentation above
5. Add front end code to save the access token and refresh token that are returned. The access token needs to be supplied with every subsequent REST request as an Authentication header with the value ‘Bearer <access_token>’.
6. Add front end code to periodically refresh the access token – this is done by posting the { access_token: …, refresh_token: … } to the /refresh endpoint.

Thanks @John Murray for making it easier to share snippets!

Have you read through the documentation? 

If you are using client-side editing, the ObjectScript extension doesn't know what git branch you are on. Check out a branch using git, and the ObjectScript extension will use those files. Your client-side source control activities are separate from your ObjectScript development activities (once again, if you are using client-side ObjectScript editing). .DAT files can also be managed in source control with the proviso that GitHub has a limit on how big files can be if you're using a free account.

@Michael Burstin to clarify, is it more accurate to say that the driver is looking for settings in all the .ini files listed in the above output? And do all the file locations output by odbcinst -j need to be present in the fs_usage isql output?

Thanks @Julius Kavay!

Thanks for sharing, @Robert Cemper. Always interesting to hear about the early days!

Run SQL from a file:

  DO $SYSTEM.SQL.Schema.ImportDDL("c:\InterSystems\mysqlcode.txt",,"IRIS")