[BEAM-2283] Consider using actual URIs instead of Strings/ResourceIds in relation to FileSystems

• Type: Improvement
• Status: Resolved
• Priority: P2
• Resolution: Won't Do
• Fix Version/s: Not applicable
• Component/s: io-ideas, io-java-gcp, sdk-java-core, sdk-py-core
• Labels: Done stale-P2
• Assignee: Unassigned
• Reporter: Luke Cwik
• Created: 12/May/17 17:14
• Updated: 06/Oct/20 21:57
• Resolved: 10/Jun/20 18:46

Description

We treat things like URIs because we expect them to have a scheme component and to be able to resolve a parent/child but fail to treat them as URIs in the internal implementation since our string versions don't go through URI normalization. This brings up a few issues:

• The cost of implementing and maintaining ResourceIds instead of having users use a standard URI implementation. This would just require FileSystems to be able to take a string and give back a URI (to enable them to have custom implementations in case they extend the concept of URIs with scheme specific extensions).
• The myriad of bugs that will come up because of improper usage of URI like strings and the assumptions associated with them (like https://issues.apache.org/jira/browse/BEAM-2277)

Note that swapping to URIs adds complexity because:

• Resolving URIs with glob expressions needs to be handled carefully
• FileSystems may need to implement a complicated type instead of ResourceId.

Issue Links

• supercedes: BEAM-1045 Windows OS compatibilities
• supercedes: BEAM-2069 Remove ResourceId.getCurrentDirectory()?
• supercedes: BEAM-2299 Beam repo build fails in Windows OS
• supercedes: BEAM-2298 Java WordCount doesn't work in Window OS for glob expressions or file: prefixed paths