Notes and Preparation 2.0 Release
The following is the public planning documentation that will be necessary to implement in the Tapestry 2.0 Release. 2.0 is (at the time of writing) the next Feature Release. 2.0 is also a Major release owing to the rewrite of the runtime flow (discussed below). Finally, because of the anticipated changes to the recovery file format (see redesigned Recovery Index File Format in the wiki), it's expected that 2.0 will be a breaking release.
Tapestry will rely on the following new features in 2.0:
- Re-introduction of cross-platform functionality with new Windows support.
- Redesigned RIFF recovery file to allow for new features going-forward.
- Metadata Display Mode - show what's in the backup without recovering it.
- Introduction of a "loom" Network Mode.
- At-Runtime and On-Demand integrity checks of newly-designed backups
Windows support was broken in the 0.3.0 multithreading release - this was due to the implementation of multiprocessing which was used and a lack of an elegant way to communicate between processes, which caused the script to simply fail when running on Windows devices.
Since this was a fundamentally flawed design, the feature is now being added back in, by redesigning the runtime flow of the program to allow it to operate under "spawn" conditions. The biggest change will be finding a way to pass the relevant namespace to each and every process on creation. This could be as simple as objectifying the namespace and providing it to worker processes as an argument - the only necessity would be to have all "investigation" tasks done well in advance of calling for the spawn.
To facilitate this the "Tasker" objects should have all information necessary for their runtime provided as arguments, OR objectise the namespace and provide it as an argument.
Previous versions of Tapestry rely on the presence of recovery-pkl, a simple Pickle object which was a list of dictionaries Tapestry relies upon to recover.
Going forward, Tapestry will make use of a new Recovery Index File Format, discussed in a separate page. This new file format will be a JSON object with a specific list of features, discussed in a separate wiki entry. Using this format will make it easier to test more thoroughly for changes in the format between versions, and allow for those tests to determine the difference between breaking and non-breaking changes.
To be provided by the RIFF, which should be easily extracted by Tapestry, decrypted, and contain enough information to provide suitable information to the user in a pretty-printed way for their later use. CSV out, perhaps.
This will basically be small hooks, including a way to get an alternate key to fetch the metadata package, and so forth. For the most part, Loom Mode and FTP mode are different only in the client handshake and the need for a light querying API on the loom side. Some development of Loom will have to take place before the similar implementations can be made in Tapestry.
Two checks, one at runtime and one on-demand, which compare the files extracted from the tapfile against their known-to-be-correct hashes. Use a secure hash and run at a good clip. One file/worker process, delete each file before starting the next. Should be straightforward.