I am working on a chrome extension for managing sessions.
I would like to store some data related to sessions and this is what I have found out till now:
1) Local Storage: Looks good to me, but I am afraid I may have too much data, and there seems to be quota on the storage. Also, local storage is more of a long-term cache, not too much dependable.
2) SQLite: not sure how it works. Need more advice on this.
3) Chrome Filesystem API: Available only on apps, not extensions.
4) HTML5 Filesystem API: Works on a virtual file-system
Please advise on the possible options.
What about the chrome.storage API? https://developer.chrome.com/extensions/storage
How about IndexedDB,
It's known for being great for client side apps, and has Unlimited space to store anything type of data you want.
Related
I want to build a hybrid using Ionic/Electron to run it on Desktop,Browser and Android, after doing some research i found about RxDB which by it's definition seems to fit this kind of DB usage (https://rxdb.info/)
I want to be able to store data locally in an SQLite-like storage capacity without being limited by the web browser's storage capacity and use the same api (rxdb ?) to manipulate data on Desktop (Electron), Mobile and web browser (Ionic).
Is this possible using RxDB ? if it's not i would like to know if there are tools out there capable of allowing such functionality ?
Yes this is surely possible with RxDB, you can use IDB which stands for indexed data storage, which in terms of browser means that your data will not be limited by the browser capacity, since it is stored offline in your computer,
It is limited only to your available disk space Not to the browser capacity
That is what idb adapter helps in browsers
Can we store concept value or action name values in session or is there any temporary storage?
I only found $vivContext which is available all across the session but we cant store the values there also.
Bixby doesn't support anything like this.
If you wish to store things across sessions, it's highly recommended that you use you own third-party storage solution.
By default concepts are stored across a session/conversation (mark them as transient if you do not want this behavior e.g. make them request based). However to store across sessions, you need to use an API call.
I wrote a tutorial capsule that uses an AWS dynamoDB for remote storage. It includes step-by-step instructions for how to use AWS for storing things between sessions. Please feel free to clone or fork it, and customize it for your needs.
I've got a website that will need to access a file on the file system (or somewhere) containing some template text used to send an email. I'd like a suggestion for where to store the file and how to access / find the file at runtime for both azure web roles and azure web sites.
So far, I've read about Azure Local Storage, but that seems to only be an option for web roles, and not available for azure websites (I think?). Plus, I'm not sure how the file would make its way into the storage.
The other option I was thinking about was adding the file to the VS solution and marking it as content, in which case I believe it would be deployed with the other files. But in this case, I don't know how to get the path to access the file form the .NET code. Also, with this, I believe that I would need to redeploy the entire solution in order to update the file.
I would appreciate any thoughts on this. Thanks...
Using a non-local storage system is your best approach, it is highly unlikely your speed requirements will be that intense it will need intense performance improvements.
I would recommend blob storage in the same region as your website/cloud service.
If you have extreme loads and need that file loaded rapidly, then have an in-memory cache set to 5 minutes or something low to store the template. Each time it checks the cache, if its not there it loads in the cache from storage then provides the resource.
You may look at using cache if you are getting a constant 1 request per second or higher. Anything lower than that then just stick to reading on demand directly from the blob storage.
If you really want to get something locally off the disk then do
Server.MapPath("~/YourFolder/YourFile.ext")
I don't know much about FirefoxOS hence this question.
I have an android app that ships with already prepared data saved in SQLite database. In the runtime the app copies that db to the device storage and uses it for reading and writing data. This is much more efficient than creating empty DB file and inserting data when the app first starts(e.g from JSON).
I was wondering how can I achieve the same thing in Firefox OS? Is there any way I can create IndexedDB, fill it with data and then add it to the app package as an asset?
Unfortunately this behavior is not yet supported. As Fabrice Desré mentioned in bugzilla, some of the files to achieve this behaviour is specific to gaia apps, which gecko does not have access at the moment.
By now, you will have to stick with the less efficient method (depending on the size of your db, the difference isn't that big).
Hope I was able to help,
cheers
I decided to use indexeddb to store data for a chrome extension I wrote. I've noticed that if I remove the extension and readd it, the data is lost.
Is there a way to persist the database across re-installations?
The apps docs (which also applies to extensions) recommend using storage.sync to handle persistence across re-installations, but the quota is very limited: 102,400 bytes. And it's not the same thing as indexeddb so some data processing would need to be done.
If your data is bigger than that I think the only solution is to sync your data manually with a server-side component, either your own or some other cloud-based solution like Firebase:
https://www.firebase.com/blog/2013-03-06-power-your-chrome-extension-with-firebase.html
Indexeddb is temporary storage. https://developers.google.com/chrome/whitepapers/storage
Browser may clear data anytime as necessary.
Until persistent data storage is available, possibly in combine with quota management api, treat indexeddb data as temporary.