Closed xelahalo closed 1 month ago
Based on my last analysis, it seemed like there was no real potential reuse for URL
validation: it couldn't be used by WebTask
, since that needs to take the special "parameterized" syntax into account.
But, there is some potential reuse for a ParameterizedWebURL
, including validation of the URL, and embedded parameters. Maybe generic, with an enum as type parameter which determines the parameters. And, which is URL-encoding aware, which will become relevant for "device role".
Static typing of URL in a WebsiteDeviceRegistration
would be a "nice to have", but is different from the above, and the above sounds more relevant to me. I could have a go maybe this weekend. :)
support for custom schemes ( like a deep link to a smartphone based study)
This sounds like potentially yet another use case. It sounds like it makes more sense to consider the specific use cases where a URL is used (or composed) and create custom validation for those. E.g., configuring a WebsiteDeviceRegistration
with a smartphone deep link is nonesensical, and you'd want the more strict http/https.
Lastly, I think we can easily add this later without impacting the web API. I don't think this is type information which is relevant to serialize, so a "primitive serializer" would be used to serialize it as plain strings either way.
Closed as it sounds like the other parts of this PR which weren't merged need more clarity in terms of what they hope to achieve.
I made this draft so that we can continue our discussion on the
URL
orParameterizedWebURL
. There are a few to things to discuss:WebTask
Seems like a bigger task, should I create an issue instead?