This project can be restructured [/rewritten] in a more comprehensive and modular form, to achieve several goals like performance, extendability and maintainability.
For this reason, a new structure is proposed, closely resembling the old one, but with increased abstraction and modularity:
Proposition
Structure
The whole project will be divided in 5 modules/parts:
core part, which will handle the file format of the created images and the way they are represented in memory in their Object Oriented form. Hence, it is gonna have 2 sub-parts:
io which will implemented ways to store and retrieve the Satori images (json, pickle, sqlite, etc)
api which will define the Object of the Satori image
imager part, that will run, given several parameters on a host, and produce the Satori Image.
differ, that will compare 2 Satori Images and produce a Satori Diff Result object.
browser will be the module that presents a Satori Image in CLI. Standard bash commands should be available with output resembling the traditional output. find, locate and ls are some sample commands that should be implemented.
remoter part will reuse the imager code to create a Satori Image from a remote machine through [S]FTP/SSH[/SMB].
[?] viewer would be a module that presents a Satori Image in a Web interface.
Extendability
The Worker/Consumer model of the imager can be overloaded with more functionalities than using stat on files. IT can be modified in a way that a hook can be applied when any file gets processed and additional information can be retrieved. The current --hash and --filetype options can be restructured as Satori Extensions.
If additional information is stored in a Satori Image due to an Extension, the differ and browser modules (and viewer as well), have to also have a way to interpret (diff and browse), this new kind of data. Hence, the Extensions will need to have a differ and browser functionality overloading.
Portability Requirements
The project should be usable under bothWindows and Linux.
All modules needed to produce a Satori Image (core and imager) must be dependency-free
Distribution
All modules should be distributed separately (respecting cross dependencies). For example: installing the imager component should only install the core component as a dependency.
The project shall be rewritten in Python3
The project and project components should be available in PyPI and available with a pip install command.
New Features/Enhancements
It is possible that some functionality of GatherOS can be augmented in the new project. This will better serve for maintaining crucial information in a Satori Image.
Colored logs from the differ can help identifying misconfigurations.
This project can be restructured [/rewritten] in a more comprehensive and modular form, to achieve several goals like performance, extendability and maintainability.
For this reason, a new structure is proposed, closely resembling the old one, but with increased abstraction and modularity:
Proposition
Structure
The whole project will be divided in 5 modules/parts:
core
part, which will handle the file format of the created images and the way they are represented in memory in their Object Oriented form. Hence, it is gonna have 2 sub-parts:io
which will implemented ways to store and retrieve the Satori images (json
,pickle
,sqlite
, etc)api
which will define the Object of the Satori imageimager
part, that will run, given several parameters on a host, and produce the Satori Image.differ
, that will compare 2 Satori Images and produce a Satori Diff Result object.browser
will be the module that presents a Satori Image in CLI. Standard bash commands should be available with output resembling the traditional output.find
,locate
andls
are some sample commands that should be implemented.remoter
part will reuse theimager
code to create a Satori Image from a remote machine through [S]FTP/SSH[/SMB].[?]
viewer
would be a module that presents a Satori Image in a Web interface.Extendability
The Worker/Consumer model of the
imager
can be overloaded with more functionalities than usingstat
on files. IT can be modified in a way that a hook can be applied when any file gets processed and additional information can be retrieved. The current--hash
and--filetype
options can be restructured as Satori Extensions.If additional information is stored in a Satori Image due to an Extension, the
differ
andbrowser
modules (andviewer
as well), have to also have a way to interpret (diff and browse), this new kind of data. Hence, the Extensions will need to have adiffer
andbrowser
functionality overloading.Portability Requirements
core
andimager
) must be dependency-freeDistribution
imager
component should only install thecore
component as a dependency.pip install
command.New Features/Enhancements
differ
can help identifying misconfigurations.