Hi Dieter: I have been so focused on getting the release out I have not had a chance to double back and think about some of the good ideas you shared.
A common base class makes a lot of sense; I was keeping them separated to avoid accidentally stepping outside of the data directory when using FileSystemResourceStore. -- Jody Garnett On Wed, Mar 15, 2023 at 9:11 AM Dieter Stüken - con terra GmbH < d.stue...@conterra.de> wrote: > 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) > <https://github.com/geoserver/geoserver/commit/e37cad6e948d0e73447d9340027c2313cddebc7a> > 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. > > -- > > *Dieter Stüken* > > Software Engineer > > Nature Environment and Resources > > > > T +49 251 59689 40 > > d.stue...@conterra.de > > > > con terra GmbH > > Martin-Luther-King-Weg 20 > > 48155 Münster > > conterra.de <https://www.conterra.com/> > > > > Geschäftsführung: Karl Wiesmann, Uwe König > > HRB 4149, Amtsgericht Münster > > Privacy statements <https://www.con-terra.com/privacy-statements> > > > > YouTube <https://www.youtube.com/conterrachannel> | Twitter > <https://twitter.com/conterra> | LinkedIn > <https://www.linkedin.com/company/con-terra-gmbh> > > >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
