Closed radeusgd closed 11 months ago
Radosław Waśko reports a new STANDUP for the provided date (2023-12-15):
Progress: Getting all pending PRs forward - fixing some tests, a few already got merged. Work on merging URI with URI_With_Query. It should be finished by 2023-12-20.
Next Day: Next day I will be working on the same task. Continue - creating a common way to create a URI from a 'schematic' that may contain secrets inside of query or user_info. Addressing PR comments.
Radosław Waśko reports a new STANDUP for yesterday (2023-12-18):
Progress: Removed Apache dependency. Created a common URI API. Working on making tests pass It should be finished by 2023-12-20.
Next Day: Next day I will be working on the same task. Fix remaining test failures
Radosław Waśko reports a new STANDUP for today (2023-12-19):
Progress: Pulling the PRs thru reviews and CI, merged a lot. Prepared the URI merge PR for review. Discussion with Jaroslav on next steps on types. It should be finished by 2023-12-20.
Next Day: Next day I will be working on the #8549 task. Pick up some next tasks.
After some followup work and discussion, we conjecture that it may be cleaner to merge the utility of
URI_With_Query
directly into theURI
, to have more uniform handling.The APIs should be merged, we may want to add following additional methods:
to_java_uri
- a counterpart of the oldURI_With_Query.to_uri
that converts to pure Java URI, if there are no secrets - it may be useful for user's interaction with other Java libraries. It will still throw an error if there are secrests - only Enso APIs are allowed to work with those.query_arugments : Vector (Pair Text (Text | Enso_Secret))
- it may be worth to be able to query what arguments are currently in the URI, in the parsed form (counterpart toquery : Text
which returns the arguments in already encoded form).raw_query
as it can cause more harm than good -query_arugments
will be more generic and serve the purpose ofraw_
better.query_arugments
must report all arguments, both ones parsed byURI.parse
as well as added withadd_query_argument
- there should be no distinction between how an argument was added.URIBuilder
instead of raw URI, as that allows to parse the query args and allows for easier manipulation of the URI./
operator to URI that allows to extend the path with additional fragments, analogously toFile./
.