Hi Jody.
since my suggestions about the Resource API have been accepted now, I think about all the other ideas on my mind.
But it is not a big shot to change the API in general. Most of them are just improvements to reduce boilerplate code.
So instead of creating an extensive GSIP I may just continue to propose further concise PRs instead.
And I’m still about to get the full picture.
I analyzed all the commits to FileSystemResourceStore to get a better understanding about the problems raised in the past.
And I just found some additional Wiki pages beside GSIP-106 itself.
I’m still unhappy with both ResourceAdaptor implementations from Files and FileSystemResourceStore.
As I understand it, Files.ResourceAdaptor was a quick and easy replacement of File, and only files, not directories.
This, however changed with Resources: support directories (7.10.2015) when both implementations became nearly the same.
Unfortunately, all upcoming fixes went into FileSystemResourceStore.ResourceAdaptor only, while Files.ResourceAdaptor mainly remained the same. May be I did not get the purpose of Files.ResourceAdaptor, but I think the grown common code has to be put into a common base class instead. If there is a strong reason to have different implementations this should be clearly expressed by overwriting the affected method.
Any reason not to do so?
I have many more suggestions/question, but this one may be a starting point to clean up the code base in general without changing the API itself.
Dieter.