tidy up

[plastikfan]

• tidy output and replace with log entry as appropriate
• remove old commentiing

[plastikfan]

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]
*/

[plastikfan]

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
*/