Shh! Totally top secret… come here… really close… 
The upcoming Spark.publish() feature will include a very simple key-value store… that’s what the TTL is for.
Like I said, this is just between us. 
4 Likes
Looks great from the firmware end. I read in another thread the spark web service will allow webhooks to be configured.
Is that coming in the same release? I’d like to get these events forwarded on to my web app.
Key/Value store? I recommend Redis! 
Using Berkley DB (Full disclosure : I work for Oracle) for Key Value store… just wrote a trivial REST wrapper around it…
Plan to right one for the mighty Oracle Database as well… nothing like an overkill…
Berkley DB vs Redis: http://db-engines.com/en/system/Berkeley+DB%3BRedis or http://vschart.com/compare/berkeley-db/vs/redis-database
Berkley DB: 1748k
Redis: 30k
Redis is also faster (in memory) and supports concurrency. Plus Redis is event-driven - supports Push like queue messaging systems.
(BTW Oracle is good for modeling the Universe, although it does not have a Boolean data type )
Which Berkley DB are you talking about we have 3. Granted the Java database doesn’t support concurrency but like Redis (Single Threaded) it’s usually front ended by a web process. We just can’t think of a reason to do it for the situations it’s used in. The C version does support concurrent processing is and multithreaded to boot. Obviously if you want a truly scalable noSQL concurrent engine you might want to use Oracle noSQL… Which is crazy fast and massively concurrent… To be fair to Berkley DB it’s used as the foundation of plenty of the biggest most concurrent noSQL engines in the industry…
As for no boolean datatypes in Oracle… Yes thats true for the database (PL/SQL does). I’ll see what I can do…
Apologies for rising to the bait
I’m working in one company as a Java dev, which is developing integrated clinical information systems. We use Oracle with PL/SQL and for boolean, we have to store it as some different data type, which sometimes leads into tri-state value problem (0, 1, or null 
).
If I had to choose some noSQL, I would defo go with MongoDB!!! Used it in the past for document-oriented ajax-based browser system and json integration is nice as well.
Hey Kareem,
Webhooks will probably come a couple weeks later—SSE streams will be available first. Both are documented here:
http://docs.spark.io/#/api/reading-data-from-a-core-events
Excellent. I missed that part in the doc. Looking forward to it!
Redis already ported…
See here
1 Like
I would like to send small amounts of data to a core that is currently turned off, i.e. store a value in the cloud for later use by the core.
Consider a core placed inside my childrens’ playstation. When they do their chores I give them playing credits (e.g. 30 minutes of playtime) which I enter via an app on my mobile phone. The credits should be stored in the cloud such that when the playstation is turned on later and the core powers up, it can fetch the data from the cloud and allow them to play for the designated amount of minutes before pulling the reset switch on the console.
So I would like to see something like a persistent variable that can be be read and updated both from the core and via the HTTPS API, and it should work even if the core is currently offline. It would be fine to let the variable have some TTL and let it be automatically removed if nobody is updating it for quite a while (a day to a week).
1 Like
@krisku You can use CC3000 EEPROM for this? You can write also private function to read and write EEPROM value. Whenever your Spark disconnected from wifi Spark can still use last value.
It’s a different thing 
The core in this scenario is sleeping/powered off. Values are to be stored in the cloud and later pushed to the core. So the EEPROM is not the one to be used.
I won’t want to touch the CC3000 EEPROM even when eventually we can, cos there’s already and external flash. Messing with the that EEPROM can really brick the wifi-module if you are not careful