I noticed that the Google Group had disappeared also - a great shame as it was searchable and had years' worth of valuable material in it. I've often used it to get answers to issues.
Wonder if Google can be persuaded to re-instate it?
Why restrict yourself to Zen? QEWD will work with pretty much every version of Cache:
Chris
I've not looked at the V4 Signature rules in detail, but the V1 & V2 rules were implemented in this SimpleDB Client that I created years ago for use with both AWS SimpleDB and my M/DB clone:
https://s3.amazonaws.com/rtweeddata/simpleDBClient.xml
Not sure if that helps, but feel free to adapt as needed if it provides a useful starting point - start around line 426 which is the createHTTPRequest() function that creates a signed HTTP request
Rob
...of course you could just write your logic in JavaScript and access Cache as a document database: http://www.mgateway.com
You can follow what's going on in this area here:
https://groups.google.com/forum/#!forum/enterprise-web-developer-commun…
Some interesting stuff been happening lately
I guess imitation is the sincerest form of flattery...
You could go a further step and run a JavaScript-based terminal console in a browser and hooking it up to Cache via Node.js.
See https://robtweed.wordpress.com/2014/03/03/ewd-js-and-vista-adding-a-jav… for an example implementation
These days, you could use something like Electron to create what appears to be a Windows application, but in fact is a packaged up Chrome & Node.js environment. In fact, IMO, this is how Atelier should have been implemented.
Remember that as soon as you have something such as this running in a browser, security (ie who has / hasn't access to the application running in the browser) becomes a major issue - you're giving command-line access to your Cache database!
and some newer stuff, in presentation slide format:
The very much more elegant forEach construct is precisely what the EWD 3 ewd-document-store JavaScript abstraction of Global storage provides you with. See:
For traversal within ranges, see:
See also:
https://github.com/robtweed/ewd-document-store
Rob
"Perhaps the most difficult concept in Caché/MUMPS is its Global Structure."
A diagram or two might help get the concept of Global structure and the purpose of the $order function, as I've done here in explaining its cache.node implementation:
http://www.slideshare.net/robtweed/ewd-3-training-course-part-19-the-cachenode-apis
from slide 31
IMO that's a depressingly risk-averse approach. The whole point of the IoT area and the Raspberry Pi is that it's still largely unexplored "solution looking for a problem" territory, where people try novel ideas out because they can and because it's cheap and easy to do so. Sure, you can wait until the market-place is clearly defined and then provide your own "we can do that too" option (and effectively miss the boat as a result), or you can be truly innovative and put it out there and see what happens, potentially catalysing ideas as a result of it being there.
That's been my philosophy for the last 20 years - if I'd been waiting for people to give me use cases, I'd not have developed a thing in all that time.
In answer to your question:
"Can anyone recommend any tutorial or code example with installation instructions?"
I'd recommend reading through the comprehensive training course on EWD 3 at http://www.mgateway.com - click the Training tab there for details
The EWD 3 module called ewd-xpress provides a ready-to-run and easy-to-use Node.js-based platform for your Cache applications. It uses cache.node to provide the connection to Cache and abstracts its APIs to make Cache behave as persistent JavaScript objects and a fine-grained Document Database. The online course will explain all!
Probably so, Herman - that's why I always hoped for the much more lightweight GlobalsDB to be ported to ARM.
Quite so, Evgeny. The question is why not?
I assume that as part of the initiative to enter the IoT marketplace, an ARM port of Cache is on the cards anyway?
if so, it might as well also run on the Raspberry Pi!
Needless to say, people are wanting to use databases, for all sorts of reasons, on the RPi - eg https://www.raspberrypi.org/forums/viewtopic.php?f=34&t=142506
and of course, they're ending up using the other usual databases that have made the investment to port to it. So the RPi community remains unaware of what Cache could potentially do for them instead.
Seems like a missed opportunity to me, but there you go.
Yep, self-fullfilling prophecies have a knack of failing, Timur :-)
Interesting to see this talk being advertised today:
https://jaxlondon.com/session/no-one-at-google-uses-mapreduce-anymore-c…
The world has moved on, it seems.
With Node.js versions coming in thick and fast, the question: "where do I get the appropriate version of cache.node?" is increasingly a problem for people who want to use Cache with Node.js.
Bundling the latest versions of cache.node with build kits for the latest versions of Cache makes little sense - people need to use Node.js with whatever version of Cache they currently have installed and use. If they update Node.js (which, as I say, is a frequent requirement these days), they won't want or expect to update Cache too. So currently you have to download a Cache kit and install it on some temporary machine just to extract the latest cache.node files.
Instead, can I request that the cache.node kits are distributed separately in a location that users can know to look for?
Anyone else agree?
Rob
The web site seemed to be quietly taken down some weeks ago. Despite what the text that now comes up says, the download files appear to no longer be at their original URLs.
I have saved copies of the distribution files, read-me and original license (which permits re-distribution). If you're interested, email / PM me for info (rob dot tweed at gmail dot com)
The web site seemed to be quietly taken down some weeks ago. Despite what the text that now comes up says, the download files appear to no longer be at their original URLs.
I have saved copies of the distribution files, read-me and original license (which permits re-distribution). If you're interested, email / PM me for info.
If you're anything like me, you'll want to try out all this Node.js and EWD 3 stuff on a separate throwaway Virtual Machine or EC2 instance. If so, take a look at this "installer" file that I've created:
https://github.com/robtweed/ewd-3-installers/blob/master/ewd-xpress/install_cache.sh
It's designed for use with a new "virgin" Ubuntu machine/virtual machine. It's not really an installer script as such - there are a few steps that, by necessity, would have to be done manually, but you may find it a helpful set of steps to cut and paste into a terminal window, or to adapt for your own use into a proper installer. I've added comments in all the places you'd need to do something manually or modify the script.
Anyone familiar with other flavours of Linux should be able to adapt it.
What will it do? It contains the instructions you need to:
Hopefully this "script" will allow you to get a system up and running to play about with in just a few minutes.
Thought some folks here might also find this useful: here's how to create Node.js-based Web- and REST services for your Cache system using EWD 3:
https://groups.google.com/forum/#!topic/enterprise-web-developer-commun…
One of the really exciting and powerful technologies that Cache developers should be looking at is GraphQL which has been developed by Facebook:
EWD 3 makes it very straightforward to integrate GraphQL with Cache. I've put together a simple React.js-based example / demo with explanatory notes here:
https://groups.google.com/forum/#!topic/enterprise-web-developer-commun…
Benjamin
In my opinion, your questions are important: I'd summarise them as follows:
- is this new Document model an attempt to bring Cache to the attention of a new audience and marketplace, or is it really just targeted at the incumbent user-base as a means of persuading them not to migrate to competing Document databases such as MongoDB?
I'd like to think and hope it's the former rather than the latter.
Many of you will be aware that I (and George James) have been championing the cause for Cache as a universal NoSQL database since as along ago as 2010, in fact very soon after the whole NoSQL movement burst on the scene in late 2009. We saw this as a great opportunity to raise the profile of Cache. I'm pretty disappointed that 6 years later, I'm yet to come across anyone I meet in the IT mainstream who has heard of Cache, despite its powerful NoSQL capabilities.
There are a number of reasons why we're still in this position of obscurity, but what has become clear to me in the intervening years is that there's one really key stumbling block: almost nobody out there wants to have to learn a new and obscure (and many would say antiquated) language in order to access a database, no matter how powerful and flexible that database.
If the objective is to bring Cache to the attention of that new NoSQL-focused audience, it's become clear to me that all its database capabilities have to be accessible via the language(s) that people already use. Since it's also clear to me that the major language adopted by the NoSQL marketplace is JavaScript, then it makes sense that JavaScript must become a first-class language for Cache if it's to stand any chance of the wider recognition it deserves in the NoSQL world.
Unless the new Document database capabilities of Cache are available directly from JavaScript, unfortunately my conclusion is that its only real audience is the incumbent user-base who are happy to continue using Cache ObjectScript and Cache's built-in programming environment.
See my recent posting on EWD 3 for my approach: my target audience is the JavaScript developer in search of something rather more interesting and powerful than the usual NoSQL databases, not the incumbent COS-oriented developer, who may not see the point in EWD 3, Document databases and all this JavaScript stuff!
There's a massive opportunity out there, but nearly 7 years since the NoSQL party began and 5 years since the JavaScript party began, I worry that the new Document database capability is too little, too late to be invited to either.
1) ewd-document-store is primarily designed for use by the JavaScript developer who wants to use / access a Cache database without needing to learn or use COS, or for anyone wanting to migrate their logic to JavaScript whilst retaining Cache as a database.
2) it works with any version of Cache that supports the cache.node interface (at least 2012.x onwards)
3) It can be used against existing/legacy global storage as well as new storage.
4) It's free Open Source (Apache 2 licensed)
Read the documentation for more information.
If you're coding in JavaScript within Node.js and want to access a Cache database in JSON / document database terms, it's worth knowing that you can use the abstraction provided by the ewd-document-store module (http://gradvs1.mgateway.com/download/ewd-document-store.pdf). Additionally, this module isn't limited to 2016.x.
The simple answer is that JSON can't naturally represent a node that is both an intermediate one and a leaf one , unless you introduce some arbitrary convention for defining a "special" node that represents a value also held by an intermediate node. There's no "standard" convention for this, since, from a JSON point of view, such a situation doesn't make sense.
The way I've tackled this with the Node.js ewd-document-store module (http://gradvs1.mgateway.com/download/ewd-document-store.pdf) which abstracts global structures directly to JSON, is to provide not only a JSON mapping (via the getDocument() and setDocument() methods, but also have a read/write value property for any specified "DocumentNode". If you use getDocument(), you'll not see any values for intermediate nodes, but separately you can home in on such nodes individually and access their data via its value property.
A DocumentNode's "exists", "hasValue" and "hasChildren" boolean properties can be used to determine the nature of each node. In truly JSON-mapped global structures, hasValue and hasChildren will be mutually exclusive, whereas it's quite feasible for (typically legacy) global structures to have DocumentNodes where both are true.
Ideally the solution is to never have global structures with data values for intermediate nodes, but typically the problem is a legacy one.
Native Mobile Cache-based app development is now possible in JavaScript using React Native and EWD 3. For instructions, see https://groups.google.com/forum/#!topic/enterprise-web-developer-commun…
The benefits are huge: just one language (JavaScript) for front-end and back-end app development on all platforms, one development pattern for front-end UI development on both desktop and mobile platforms, and the opportunity to re-use the same back-end logic for desktop and mobile apps.
Additionally, just like desktop browser-based apps, with EWD 3 and React Native, Mobile apps can use WebSockets instead of REST to access the back-end and Cache.