Future plan

I plan several improvements. The order is not defined since I change my way according to my will. But here are some of them:

• Implements all functions of import, get, check and admin for Multiple OpenLSD support. Right now, Import, check and admin are supported on Multiple OpenLSD support, that is to say a mirror of the documents handled by OpenLSD for each Legacy defined inside the Database.

What is ready: Import, delete, check and admin for ML OpenLSD support.

 

One goal is to allow of course the replication and therefore the security of the archiving process.

Another goal is to allow more availability of the concerned Legacy by allowing one user to ask documents from any OpenLSD servers that implements this Legacy in parallel or in the reverse way to import documents to any OpenLSD servers that implements this Legacy in parallel. These two last points are not yet implemented but are not difficult to do.

• Create a full cache support, both in read and write. The main idea is that a user can use a client that communicates with a local (or close) cache OpenLSD server.

If the user asks for a document, this document will first try to be retrieving from the local cache, and if not present, it will be retrieve from one of the OpenLSD servers and store also in the cache server for a next request until a certain time. The storage in the cache server is of course less than the OpenLSD Server and is supposed to be up to 2^64 documents, but we recommend to limit it to a number as small as possible. Perhaps some optimization will break up this limitation. The storage can be also crypted (using a different key than the Server one) and documents are stored for a short time only (there will be a parameter standing for valid hour delay like a web cache).

 

If a user (or program) ask to import a document into the system, the cache will be as a write cache, that is to say it will be first written to the local (or close) cache OpenLSD server and immediately returns the control to the user (or the program). Then the import of the document is done in an asynchronous way between the cache server and the final OpenLSD server (or one of them in case of multiple OpenLSD servers).

 

One of the interests of the caching service is obviously to improve network latencies between the main system and the users.

 

Another interest is that for the import part it will allow to not give the access to the central database from any client. Indeed, the cache server will act as a simple cache for the final process of import of the document. The only process to access to the central database will be the final importer process and not the cache or client process.

• Make the version using MySQL and also PostGreSQL as efficient/functional as the one with Oracle (or close).

• Improve OpenLSM (email archiving based on OpenLSD) since its first version is running OK but should have some improvements on business part... ;-)

• And of course continue to clean the code, refactorize when needed and debugging any bug that I didn't found yet...