go to post Rob Tweed · Jan 10 Well it only took 13 years for the idea to be taken up. https://www.mgateway.com/documents/universalNoSQL.pdf
go to post Rob Tweed · Jan 5 An observation: the administrators of this forum regularly report the size of this community, currently an impressive number in excess of 12,000 developers, yet, as can be seen from the OP, numbers of views of even the most popular posts is tiny by comparison. From what I've seen, a typical post will get around about 50 views, and each comment will add a further 50 - a meagre 0.4% of the total community. This leads me to believe that there is actually only a small core (~50?) of regular contributors and readers (many of whom, I suspect, are actually ISC employees) It does make me wonder what, if anything, most of those 12,000 Cache/IRIS developers read, and what site(s) they use instead. Perhaps they don't read anything? My reason for raising this is that, for a third-party developer of solutions for these technologies, reaching and informing those 12,000 developers is a significant issue and problem, and it's fairly clear to me that this forum currently doesn't provide a very effective solution to that problem. My question/challenge for 2023 is therefore what do folks here (the regular 50?) think can be done to provide a more effective way to reach that reported developer base?
go to post Rob Tweed · Dec 13, 2022 Use the tried and tested mg_python: https://github.com/chrisemunt/mg_python
go to post Rob Tweed · Dec 7, 2022 If the applications you're providing to users are REST/web/browser-based, you can make use of connection/process pooling, eg via an implementation in another back-end language, to avoid/minimise these issues. A good example is the Node.js/JavaScript-based QEWD framework or its recent evolution - qoper8-fastify - I've described the latter in another recent posting here on Node.js. Another alternative is to use our mg_web interface (you may want to check out our mgweb-server framework which packages up mg_web for ObjectScript-based REST APIs to save you a lot of effort): this uses modern web servers (eg Apache/NGINX) to manage connections to IRIS in a parsimonious way. Some holiday reading: QEWD: https://github.com/robtweed/qewd QOper8-Fastify: https://github.com/robtweed/qoper8-fastify Using QOper8-Fastify with IRIS: https://github.com/robtweed/qoper8-fastify/blob/master/IRIS.md mg_web: https://github.com/chrisemunt/mg_web mgweb-server: https://github.com/robtweed/mgweb-server Take a look at our other language interfaces and front and back-end solutions too - see https://www.mgateway.com
go to post Rob Tweed · Nov 23, 2022 Well, if it was me, I'd keep that and the rest of my logic in JavaScript/Node.js and access the Cache database using the mg-dbx interface.
go to post Rob Tweed · Nov 2, 2022 ... well they don't need to develop their own. They could actively support and work with third party experts in this area and simply make available suitable public interfaces.
go to post Rob Tweed · Nov 2, 2022 I should point out that if you use the in-process API connection to IRIS from mg-dbx, you don't need to install anything on IRIS - just enable the call-in interface and away you go. You do, of course, need Node.js running on the same physical hardware as IRIS for such a connection, but it's significantly better performance than a networked connection.
go to post Rob Tweed · Nov 1, 2022 Ideally yes, I would agree, but you're up against the publicly available interfaces for IRIS. What would you suggest?
go to post Rob Tweed · Nov 1, 2022 Well of course you can use the mg-dbx interface for IRIS which is available on NPM and which provides equivalent functionality to the Native API interface. https://github.com/chrisemunt/mg-dbx Otherwise, in terms of complexity of getting IRIS working with Node.js for multi-user environments, the qoper8-fastify approach I've described makes it about as simple and easy as you can get, and all you need to focus on is the logic for each REST request handler and how it interacts with and uses your IRIS data. Use glsdb's even higher-level abstraction and it becomes even simpler for a JS/Node.js developer https://github.com/robtweed/glsdb So the solutions are all there. It's the means to communicate at appropriate scale that's missing. I've tried relentlessly over recent years, but a single lone voice doesn't get things very far, sadly.
go to post Rob Tweed · Oct 31, 2022 I wonder how many people are actually using Node.js with IRIS? My hunch is, sadly, not many, yet JavaScript is a really great modern alternative language to ObjectScript, and IRIS is potentially a really natural database for JavaScript/Node.js deveopers. How to get IRIS developers to check out and adopt Node.js, and how to get Node.js developers to check out and adopt IRIS? It's an incredibly potent combination for anyone willing to try!