Niels: We may be on the same page, you indicate ResoueceStore should never use absolute paths for the file system.
That is the decision I wish to make, and then we should go do the work to enforce it. How much work? I am not sure, hence the work party. There is something subtle here though. You are focused on the ResourceStore API, and I am asking you to consider the application as a whole. We do have paths in the application including absolute paths. The QA activity to check that these are handled correctly is the work. Paths are not only for ResourceStore. Jody On Tue, Aug 1, 2023 at 11:55 PM Niels Charlier <ni...@scitus.be> wrote: > Hello Jody, > > Unfortunately I am not really on board with your plan. I really don't > think we need to make a new branch and do a lot of work. This seems like a > lot of unnecessary work. I think the original design is fine, and does not > require breaking the code base. We just need to go back to how things were > and perhaps fix a few cases where people have gone wrong since then. > > > - > > Gabe and Niels are having trouble with the API changes made earlier > this year > - > > The definition of path was inconsistent for windows absolute paths > > I disagree. The definition of 'path' for the resource store is not in any > way related to the OS, because the resource store lives in a separate world > from the file system. The resource store and the file system have no joint > concept of 'path'. > > - > > Early resource store work was not strict about use of paths, and when > to use Resource and when to use File > > I disagree. It was always very clear about this. There should obviously > never be hard coded absolute paths for the file system. In general the code > should basically always use resources. Only where users can use URLs they > have access to both the file system and the resource store, this is always > how it was intended to work, as can be read from the javadoc. > > - > > The email conversation is going in circles because something has to > break > > > - > > We have to accept that something that break > > I disagree. I think nearly all of the code base is fine with how it was > designed to work. > > Regards > > Niels > > On 01/08/2023 19:31, Jody Garnett wrote: > > Niel, Gabe: > > Our email thread on this topic has explored the topic by now, I think > action rather than more communication is needed next. > > Can we setup a 1/2 day breakout work-party to get this activity underway > (prior to the Bolsena code sprint and the next release cycle). Even a > couple hours to get the topic started on a branch would be great. > > I am proposing two times below, and am willing to wake up early to see > this topic move along: > > > 1. August 8th > > <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023&month=8&day=8&hour=13&min=0&sec=0&p1=256&p2=45&p3=48> > 15 > CEST / 11 BRT / 6 PDT > 2. August 15th > > <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023&month=8&day=15&hour=13&min=0&sec=0&p1=256&p2=45&p3=48>: > 15 CEST / 11 BRT / 6 PDT > > > Is this a good idea :) > -- > Jody Garnett > > -- -- Jody Garnett
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
