JIO saves his job queue in a workspace which is localStorage by default. Provided storage descriptions are also stored, and it can be dangerous to store passwords.
The best way to create a storage description is to use the (often) provided tool given by the storage library. The returned description is secured to avoid clear readable password. (encrypted password for instance)
When building storage trees, there is no limit on the number of storages you can use. The only thing you have to be aware of is compatability of simple and revision based storages.
Three methods are provided:
- createDescription(username, [application_name], [mode="localStorage"])
- createLocalDescription(username, [application_name])
- createMemoryDescription(username, [application_name])
All parameters are strings.
Examples:
// to work on browser localStorage
var jio = jIO.createJIO(local_storage.createDescription("me"));
// to work on browser memory
var jio = jIO.createJIO(local_storage.createMemoryDescription("me"));
The tool dav_storage.createDescription generates a dav storage description for no, basic or digest authentication (digest is not implemented yet).
dav_storage.createDescription(url, auth_type, [realm], [username], [password]);
All parameters are strings.
Only url and auth_type are required. If auth_type is equal to “none”, then realm, username and password are useless. username and password become required if auth_type is equal to “basic”. And realm also becomes required if auth_type is equal to “digest”.
digest is not implemented yet
Be careful: The generated description never contains readable password, but for basic authentication, the password will just be base64 encoded.
Updating to v2.0
Updating to v2.0
This handler indexes documents metadata into a database (which is a simple document) to increase the speed of allDocs requests. However, it is not able to manage the include_docs option.
The sub storages have to manage query and include_docs options.
Here is the description:
{
"type": "index",
"indices": [{
"id": "index_title_subject.json", // doc id where to store indices
"index": ["title", "subject"], // metadata to index
"attachment": "db.json", // default "body"
"metadata": { // additional metadata to add to database, default undefined
"type": "Dataset",
"format": "application/json",
"title": "My index database",
"creator": "Me"
},
"sub_storage": <sub storage where to store index>
// default equal to parent sub_storage field
}, {
"id": "index_year.json",
"index": "year"
...
}],
"sub_storage": <sub storage description>
}
Updating to v2.0
Comming soon
A revision based handler is a storage which is able to do some document versioning using simple storages listed above.
On JIO command parameter, _id is still used to identify a document, but another id _rev must be defined to use a specific revision of this document.
On command responses, you will find another field rev which will represent the new revision produced by your action. All the document history is kept unless you decide to delete older revisions.
Other fields conflicts, revisions and revs_info can be returned if the options conflicts: true, revs: true or revs_info: true are set.
Updating to v2.0
Updating to v2.0