Re: [VFS] Should relative name be decoded

2025-04-16 Thread Bernd Eckenfels
Need to correct myself a bit: the change which prompted for my initial mail is not about escaping blanks in getPath(), getPath() (Depending on the provider) only escapes % (and ? and !). So the missing decode Variant of getRelativeName is limited to those. The escaped blanks happen in getURL an

Re: [VFS] Should relative name be decoded

2025-04-16 Thread Gary Gregory
Yeah, this needs more research IMO. One things I am sure of is that a global setting is a no-go for me as it is bound to cause problems in larger apps that may want conflicting values. Gary On Wed, Apr 16, 2025, 12:48 Bernd Eckenfels wrote: > > I think the encoding caused a lot of confusion wi

Re: [VFS] Should relative name be decoded

2025-04-16 Thread Bernd Eckenfels
I think the encoding caused a lot of confusion with people (and also I dont see how it is user friendly - besides if the calling Convention required it), but I dont think we can change that now. So I agree with Review and documenting. Maybe we need to provide at least a UriParser.decode() publ

Re: [VFS] Should relative name be decoded

2025-04-16 Thread Gary Gregory
Hi all, We probably need a general review of the API to see if we have an overall consistency issue RE encoded vs decoded. I prefer us to be considerate before adding APIs here and there. We could at least document what is expected for methods that return a String or consume a String. I wonder