search

atlas-engineer / nfiles

User configuration and data file management
BSD 3-Clause "New" or "Revised" License
18 stars 5 forks source link

Point of virtual files? #15

Closed Ambrevar closed 1 year ago

Ambrevar commented 1 year ago

In commit bb3c5e67ca85921e9c9da807d5957363b8a276e8 we've made viritual-files resolve to the empty path so that they don't use the cache.

Indeed, being in-memory data, there is no need for caching. Caching virtual files would mean that multiple instances would share the same data, which is not always wanted.

However, what's the point of virtual files, now? Previously, there were used solely for the dynamic path expansion capability of Nfiles (like Nyxt's config file). But now it seems that they have no feature at all!

I suggest we revert bb3c5e67ca85921e9c9da807d5957363b8a276e8 and find another way to (optionally?) disable the cache.

@aartaka ?

Ambrevar commented 1 year ago

Actually I wonder what the problem is with having multiple virtual-files share the same cache. I can't recall. Any idea @aartaka ?

aartaka commented 1 year ago

The only application for virtual files that I can remember is user scripts. And in this scenario, file caching is actually useful, so it's bad it was turned off.

File paths are useful indeed, but why not use a regular nfiles:file for that, not using it for anything else?

Beyond this use-case, I haven't used virtual files much, so not sure I have any stance on any question here （ノ￣ー￣）ノ

Ambrevar commented 1 year ago

File paths are useful indeed, but why not use a regular nfiles:file for that, not using it for anything else?

The point of virtual files is to guarantee that no disk read / write will be done.

Can you explain how user scripts would benefit from caching? If they are virtual, means they don't need a path, right?

aartaka commented 1 year ago

File paths are useful indeed, but why not use a regular nfiles:file for that, not using it for anything else?

The point of virtual files is to guarantee that no disk read / write will be done.

Hmmmmmmm...

Can you explain how user scripts would benefit from caching? If they are virtual, means they don't need a path, right?

Use scripts that are virtual need to be fetched from the remote URL every time. If we cached them, that'd make for a much more stable and offline-friendly user script usage.

But then, yeah, if virtual-file is for no read/write at all, then we should have some other thing for this use-case...

Ambrevar commented 1 year ago

Use scripts that are virtual need to be fetched from the remote URL every time. If we cached them, that'd make for a much more stable and offline-friendly user script usage.

Wait, don't we also provide a file name for user scripts with URL so that they are saved to disk, to avoid re-fetching them next time?

Also I just checked the code:

(define-class user-script (renderer-user-script files:data-file nyxt-remote-file)

User scripts don't seem to be virtual.

aartaka commented 1 year ago

Oh right, then it's irrelevant.

Ambrevar commented 1 year ago

Just remembered why I made virtual-profile return #p"" in https://github.com/atlas-engineer/nfiles/commit/bb3c5e67ca85921e9c9da807d5957363b8a276e8 : it's for files that use nfiles:expand but for which reading and writing is done by a third party (like the WebKit files in Nyxt).

  1. This change only makes sense for virtual-profile, not for virtual-file. The point was to have a single knob to disable reads and writes for the whole application.
  2. That said, I wonder if it's a good idea anyways, because
    • we lose information of "where would the file be stored if it were not a virtual profile"
    • the third party might not know what an empty file means and decide to read / write none the less.

So the question is, how do we disable reads and writes for the whole application, even for files that use a third party? Maybe there is no good answer to this... @aartaka @aadcg @jmercouris

aartaka commented 1 year ago

The functionality of emptying paths seems to belong to a profile, yes. And it seems to be the best way to disable writes at the level of application too.

We can resolve the file against another profile to find the actual path, no? Doesn't seems like a problem here. And third-party is third-party, we'll be writing wrappers for it anyway.

Ambrevar commented 1 year ago

We can resolve the file against another profile to find the actual path, no?

Not directly, because the profile belongs to the nfile profile slot. So nfile:expand would not work. But one could call nfile:resolve MY-PROFILE MY-FILE where MY-FILE has a profile different from MY-PROFILE. That should work.

Ambrevar commented 1 year ago

Fixed with #16.