generated from snivilised/arcadia
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tidy up #114
Labels
refactor
Refactor code
Comments
old Path finder comments // INLINE-MODE: EJECT | INLINE (should we call this a strategy?
// they do the same thing but create a different output structure => OutputStrategy)
//
// EJECT: replicate the source directory struct but eject elsewhere
// INLINE: create the file at the same location as the original but rename as required
// The controller is aware of the output strategy moving files accordingly,
// using the path-finder to create the paths and the file-manager to interact
// with the file system, using a vfs.
// Then we can also have a deletion strategy, use a central location or inline
// CENTRAL-LOCATION: is like EJECT
// INLINE: INLINE
// Can we have 2 different strategies at the same time?, ie:
// OUTPUT-STRATEGY: INLINE
// DELETION-STRATEGY: EJECT
//
// ... well in this case, the output file would be in the same folder
// as item.Path, but the TRASH folder would be relative to eject-path (ie in
// the same folder as item.Path) and the
/* eject parameters:
we can't have --eject, because ambiguous, which strategy does this apply to?
(but what we could say is --eject if specified applies to output && deletion)
- the same goes for inline, but --inline would be a switch, not a flag
==> --eject(path) & --inline [still needs a way to specify how to manage renames]
both strategies set to eject or inline(~transparent mode)
if we say this, then --inline could be redundant, ie if --eject is not set,
then we revert to the default which is eject(transparent)
-- then other flags could adjust the transparent mode
if --eject not specified, then ous=inline; des=inline
but it can be adjusted by --output <path>, --trash <path>
-- perhaps we have a transparency mode, ie perform renames such that the new generated
files adopt the existing files, so there is no difference, except for the original
file would be renamed to something else. With transparency enabled, we make all the
decisions to make this possible, we internally make the choice of which strategies
are in place, so the user doesn't have to work this out for themselves. But the
deletion strategy is independent of transparency, so it really only applies to output.
Or, perhaps, do we assume transparent by default and the other options adjust this.
so we have 3 parameters:
* neither --output or --trash specified [ous=eject; des=eject];
* --output <path> [ous=eject; des=inline]
* --trash <path> [ous=inline; des=eject]
* --output <path> --trash <path> [ous=eject; des=eject]
*/ |
misc path-finder comment /*
*** item-handler
contains:
- the Program
- positional args
- third party CL
- path-manager
*** path-manager needs to provide the following paths
- output directory (inline | eject)
- trash file location (central or local)
- for sampling scheme, we use profile name as part of the relative output path
- output root (depends on eject)
behaviour of naming output files:
- output filename (same as input file with a suffix | backup input, replace input file)
- this is where the extension mapper will be implemented
*** file-manager: perform file system operations such as moving files around
- there will be a file-system service that can perform fs operations. it
will contain the path-finder
- contains file manager as a member
- is populated with the current traversal item
the sample mode is a bit tricky because for 1 file it will do multiple things
we need to capture that concept somehow
- foreach incoming file
FULL: => a single output file
SAMPLE: => multiple files, foreach each profile in the sample create an output
*/ |
plastikfan
added a commit
that referenced
this issue
Jan 12, 2024
plastikfan
added a commit
that referenced
this issue
Jan 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: