Le lundi 7 d?cembre 2020, 19:00:02 CET colecmac at protonmail.com a ?crit : > C?me's reply here asserts that a client would never need to parse > IRIs, and so there's no added complexity. Just copy the IRI from the > link line, do DNS, and send the IRI to the server. But this is not > true, a client would need to do parsing. > > What parsing would a client have to do? > > - Extracting the domain, so it can be punycoded for DNS lookups True, thanks for pointing that out. > - Resolving relative IRIs would require parsing the current IRI, > and the provided one, and combining them. You cannot just copy it > to make the request. Also true, but it should be the same value that is extracted for DNS. > - When receiving an input status code on a page that already has a > query string, the IRI has to be parsed to detect that there is a > query string, and then remove and replace it with the new input of > the user. Good to know, I did not think of query string situation. > - Extracting the path to get a name for downloading files > - Etc. > > There are many reasons why a client would need to be able to parse an > IRI, the relative link one and DNS one being the most important. > > This would then require IRI parsing libraries, and as I have explained > earlier, these don't exist in likely many programming languages, and > when they do, they are third-party. From what you said on irc, the situation is different between URI and IRI because most languages have URI parsing either in their stdlib or in a well tested known library. But, if no project use IRI, of course no one will write a library for it, this is a chicken and egg situation here. Also, for the purpose of a client, it seems to me the parsing needed (domain and query extraction) is only to search for the first "/" and the last "?", and some minor tweaks on the scheme maybe (which does not contain unicode, I will leave the scheme alone, promise). Note: Just tried gemini://gemini.circumlunar.space/%64%6f%63%73/%66%61%71%2e%67%6d%69 in lagrange, it does work. C?me
---
Previous in thread (49 of 68): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (51 of 68): 🗣️ colecmac (a) protonmail.com (colecmac (a) protonmail.com)