ms-painter / folden Goto Github PK

Check if attempt to register a path is already a child path of any other registered handlers.
Disallow this to make handlers simpler to manage and less likely to cause destructive issues with conflicting handlers

How many handlers are allowed to be up?

Should there be a limit to how many can be registered?

Configurable by user? Adjusted at runtime by server side main thread?

Currently unsupported syntax

Seperate to the workflows.
Any running handler currently prints to console progression or issues.
These messages should be instead handled in a way which could be interwoven into logging and possible runtime tailing.

Each mapped handler to dir can be modified to send output to a known exporter such as a db or log file.

Runtime tailing of a handler's traces/logs should be integrated with the previous part and in some way grpc server to client streaming using tonic.

Allow methods of supported logging to be chosen between:

• No logging
• Env logger (Windows only) logs visible in EventViewer
• Rolling file logs
• Database support

The moved/uploaded file will be the one that will be saved to mapping file

Currently the server mapping data can't be serialized.

This is because of the thread sync sender object stored for each handler,

Which allows us to send messages to handler threads.

We'd want to de/serialize the mapping object to allow starting up handlers already registered on service startup.

Can we store a different object to use to access the sender object through?

Can the sender object on the mapping object be omitted from de/serialization?
Since it would be dead anyways and has no use for the starting up service as it would re-create threads and update the mapping anyways.
Alternatively implementing a de/serialization for this field on the mapping which would store a dead fake sender object.

Option between event based and schedule based.

Schedule based would run like startup phase on event based. On each file in directory based on ruleset.
Schedule could be provided like cron based formatting (* * * * *).

Ensure no file in the directory has the same content as the event file

Assign in array all supported ones on file creation

Decide on default port

Allow configurability of port

Wrap grpc inter process server with tls and provide way for clients to supply or store tls certified servers allowed to connect to

Events are categorized with sub types such as
CreateKind(Any), CreateKind(File), CreateKind(Other),
ModifyKind(Any), ...

Allow to decide on which of these to accept at [event] workflow configuration for each type of accepted event:

[event]
handle_create = ["File"]
handle_modify = ["Any"]
naming_regex_match = ".*"

Detect on startup if the process of foldend is alive and if it is exit runtime with an appropriate message.

Generic action?

Publish action/s for different destinations; Ex.:

• RabbitMq
• MongoDB
• MySQL
• Splunk
• Redis
• Email

Upgrade tokio stack usage to v1.X versions

Currently object of response is printed on client cli.

Formatting the response in a generalized way to easily understand response.

Also needs to support multiple handler data responses.

status --all or --list....

Wrap creation, iteration and execution of subcommand in the client CLI application with an abstraction.

Instead of doing tons of if statements should just iterate over each subcommand supplied to the abstraction object -
Executing based on the inner for's if statement.

Add Handler trait which template method dictates from Watcher trait what logic should the Handler trait do at runtime.
Each handler provides implementation for Handler trait and Watcher trait implements all needed details.

Automated upload to package providers such as:

• Chocolatey
• Apt

Such as:

• Directory path on MoveToDir action
• Command on RunCmd action

Including separate build for M1 arch

Support for bash, zsh, etc...

No need to generate it and supply for each subcommand.

maybe lazy static?

Client & Service side:

• Command to configure if to start handler (or all) on service startup

Handler side:

• Clarify config option of apply on startup as to attempt to apply workflow on existing files in dir which are not part of the events.

Project logo to add to repository and as specialized image files for msi installer

Publisher destination send an http request to a set destination.
Supply details in body or url

Currently main idea is to apply one handler to a directory.

Handlers aren't idempotent or atomic currently.

New overhaul describes a way to apply multiple handlers of different order types that could fit in a structured workflow.

What if you could move to a folder then zip the resulting folder?
And what if you wanted after the zip to notify a remote target of this change via a db? Or multiple dbs?

This leads us to the this workflow structure idea:

*In the above Example Arrived relates to data (file/folder) which was just added which file watcher noticed.
**In the above Example Results relates to data results (file/folder) from previous action.
*** In the above Example Filepath relates to file path of the file (results or arrived).

Above all this is the configuration to save tracing which is relevant depending on what you want for the workflow.
So these tracings could not be stored at all or stored only locally or log rotated locally or provided as the data for tracing exported to a target of your choice from message queues to databases.

These workflows have the constraints of being single directional and cannot go backwards to potentially loop parts of the workflow.

If absolute use path in file
If relative use path in file combined with the event file path to