Introducing Limnie: an object storage library for Xojo!

Limnie: /li.?mni/ : “lake” in Greek, plural: Limnes

Limnie is a local, highly configurable, flat virtual file system. Its main use is to act as a local object store subsystem. It relies on proven, robust SQLite technology and is heavily based on the pdstorage component of the -now defunct- postdoc project (also found on GitHub)

The main features of Limnie are briefly explained below:

Local:
A Limnie VFS should always be on the same machine as the applications mounting it. It SHOULD NOT be acessed over a network share or filesystem. It might appear to work at first, but if used in violation of this core spec, you are risking corruption!
Multiple applications running on the same machine, accessing the same Limnie, is considered a safe practice.
Within the same application, one Limnie session per thread is allowed. This is a major design restriction.

Highly configurable:
A Limnie VFS consists of one or multiple storage pools that act as entirely separate “buckets” you can assign data that belong to different domains, clients, or archival projects. Each pool consists of storage media. Media are the actual containers of the content you push into the VFS. Media are initialized to a configurable size and they grow gradually towards that limit. When the last medium of a pool becomes full, Limnie can be configured to auto-create the next one at a set location and size limit. Media belonging to a certain pool can also be encrypted with a password that applies only to that pool. Furthermore, access to the entire VFS itself can also be password-protected if needed.

Flat:
Limnie does not store data in a hierarchical manner: There are no folders and subfolders. The namespace for each storage pool is flat. Every object pushed into a pool just gets an ID and is retrievable by using that ID. Your application can organize the data in any way it needs.

Virtual File System:
A virtual file system is a file system within your OS’s filesystem(s). Externally, it might appear as one or more files, but when mounted properly through the proper code libraries, your application can access their storage space in a way similar to accessing a new drive connected to the computer.

If you’re new to Limnie…

Please refer to the Quick Start Guide found in the LimnieGUI application and read the “CONTRIBUTING.md” file on the repository.
Remember: The LimnieGUI application is your definite guide on how to integrate Limnie to your own application. After all, that’s what Limnie exists for!

How this compares to http://documentation.xojo.com/VirtualVolume ?

Anything is faster than virtual volume including a SQLite database.

OK, thanks.

It’s not just speed. Not that SQLite is horribly slow, but in this particular case, speed is the least of my concerns.

The Xojo VirtualVolume is something of a hack: there’s really no documentation over what it is, how it works and how well it responds to intensive use and unforeseen circumstances. Furthermore, it’s being de-emphasized by Xojo itself, meaning its days are officially numbered.

Now, SQLite is quite the opposite of all that…

Actually, that’s the definition of Deprecated.

OK.

Not to be pedantic, but the Xojo site lists Virtual Volumes explicitly as “De-Emphasized” rather than under “Deprecations”

So you (as an org) seem to be drawing a line of distinction

ref: http://documentation.xojo.com/resources/deprecations.html

Now I remember why I do not used VirtualVolume. After trying it, I realized I have to use my software to move the data from the VirtualVolume (sometimes in the future…), not the Finder… Same apply for storing data into it.

A Package folder was better for my use (and at least, I never used a package at all).