Skip to content
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.

Refactor app filesystem code for abstraction / remove redundancy #330

Closed
1 task done
anonimal opened this issue Aug 28, 2016 · 0 comments · Fixed by #420
Closed
1 task done

Refactor app filesystem code for abstraction / remove redundancy #330

anonimal opened this issue Aug 28, 2016 · 0 comments · Fixed by #420

Comments

@anonimal
Copy link
Collaborator

By submitting this issue, I confirm the following:

  • I have read and understood the contributor guide.
  • I have checked that the issue I am reporting can be replicated or that the feature I am suggesting is not present.
  • I have checked opened or recently closed pull requests for existing solutions/implementations to my issue/suggestion.

Place an X inside the bracket to confirm

  • I confirm.

Discussed after #329, referencing #98:

&anonimal EinMByte: Hmm. Ok, so ideally all current filesystem code in app should be in core and we just need a way to interface to it through app?
* anonimal should actually pull up the code
&anonimal lol, I think I answered my own question.
&anonimal So, since app is the 'the third wheel', e.g., the throw-away piece that's only needed to run as stand-alone, EinMByte we could just abstract the calls to *something* in core, and from there within core point to the real filesystem implementation.
&anonimal EinMByte: ^ sound about right?
+EinMByte maybe, but make sure that core know nothing about app
+EinMByte (in think that was the main reason for how it's currently done)
&anonimal Yeah, exactly.
&anonimal But the problem with what we have now is that its redundant code that is confusing to maintain.
@anonimal anonimal added the app label Sep 9, 2016
@anonimal anonimal self-assigned this Sep 11, 2016
@anonimal anonimal added this to the 0.1.1-alpha milestone Sep 13, 2016
anonimal added a commit to anonimal/kovri that referenced this issue Oct 26, 2016
anonimal added a commit to anonimal/kovri that referenced this issue Oct 30, 2016
anonimal added a commit to anonimal/kovri that referenced this issue Oct 30, 2016
Our data path / data dir is hardcoded, defined at compile time. There is
nothing flexible about it: once you start the router, you it will work
within the same data directory indefinitely (though there are some
run-time options that provide *some* flexibility where some of the
data within the directory can be found/redirected).

Initializing router context (as if the data dir were a mutable type)
is unnecessary and confusing. Ideally, we would *like* as much
flexibility as possible but, for now; this lends itself to breakage.

Also, this commit moves any filesystem related confusion out of app and
into core because of said reasons (and to remove redundancy). This is
not the *ideal* abstraction I had in mind for monero-project#330 but it is good
enough for now (and solves the issue at hand).

Run-time breakage was introduced in 95b35bf because of said reasons.

Closes monero-project#330
anonimal added a commit to anonimal/kovri that referenced this issue Dec 9, 2016
- Replaces rotation by size with rotation by time
- Replaces log filename count template with date template
- Add commented code for a potential file collector (requires boost 1.61+)
- Remove un-related TODO's in the area that were resolved in monero-project#330

References monero-project#375
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants