Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New regex for matching URIs and unix file paths in libopenrave-core #1261

Open
undisputed-seraphim opened this issue Jun 19, 2023 · 0 comments

Comments

@undisputed-seraphim
Copy link
Collaborator

The current regex used to detect if a string is a URI (last revised 10 years ago) does not infact work as intended.

Due to that fact, there are multiple places that do unnecessary string comparisons to make up for the deficiencies.
For example, this function , where a MsgPack file must first run 3 fairly expensive regex matching operations (where the input are identical and results are discarded) before arriving at the function to call.

As well as these functions where the URIs are parsed and resolved again when they should have been resolved in the upper calling layers of code.

Additionally, there are separate functions for loading a KinBody or Scene depending if the intended input is a unix file path or a URI, but there is no real difference between these two (a file path is a URI without a scheme).

I'd like to suggest that first we fix the regex, then try to deduplicate the code contained in libopenrave-core. ReadRobotURI, ReadRobotFile, ReadKinBodyURI, and ReadKinBodyFile are mostly identical functions with minor variations, as are the RaveRead[JSON/MsgPack][URI/File/Data] functions.

A single Load function can detect whether a (non-data) string is a unix file or URI at the very beginning with one regex operation. The string is decomposed into scheme, authority, path, query, and fragment. A download operation is needed if and only if the scheme and authority is non-empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant