response

diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
index 80925b458287767620d8862f782e77b1bd7dda63..f8ec4c420469f47168ced54b93dbe75fa39dfdab 100644 (file)
--- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
+++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
@@ -201,6 +201,10 @@ New API added by this branch:
   >>
   >> I personally think breaking the docwiki is enough to block that.
   >>
   >>
   >> I personally think breaking the docwiki is enough to block that.
   >>

+  >>> Well, the docwiki doesn't have an url configured at all, so I assumed
+  >>> it would need to fall back to current behavior in that case. I had
+  >>> not thought about browsing wiki's html files though, good point.
+  >>

   >> How about this?
   >>
   >> * `urlto($link, $page)` with `$page` defined: relative
   >> How about this?
   >>
   >> * `urlto($link, $page)` with `$page` defined: relative


@@ -210,12 +214,24 @@ New API added by this branch:
   >>   normally undef): absolute, starts with `http[s]://`
   >>
   >> --[[smcv]]
   >>   normally undef): absolute, starts with `http[s]://`
   >>
   >> --[[smcv]]

+  >> 
+  >>> That makes a great deal of sense, bravo for actually removing
+  >>> parameters in the common case while maintaining backwards
+  >>> compatability!
+  >>> 
+  >>> It does highlight that it would be better to have a
+  >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` )
+  >>> rather than the 3 parameter form. --[[Joey]]

 
 * `IkiWiki::baseurl` has a new second argument which works like the
   third argument of `urlto`
 
   > I assume you have no objection to this --[[smcv]]
 
 
 * `IkiWiki::baseurl` has a new second argument which works like the
   third argument of `urlto`
 
   > I assume you have no objection to this --[[smcv]]
 

+  >> It's so little used that I don't really care if it's a bit ugly.
+  >> (But I assume changes to `urlto` will follow through here anyway.)
+  >> --[[Joey]] 
+

 * `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
 
   > Possibly changed to making this always be local unless `cgiurl => $x`
 * `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
 
   > Possibly changed to making this always be local unless `cgiurl => $x`


@@ -225,6 +241,8 @@ New API added by this branch:
   except `cgiurl` and/or `local_cgiurl`
 
   > I assume you have no objection to this --[[smcv]]
   except `cgiurl` and/or `local_cgiurl`
 
   > I assume you have no objection to this --[[smcv]]

+  > 
+  >> Nod, although I don't know of a use case. --[[Joey]] 

 
 Bugs:
 
 
 Bugs:
 


@@ -243,6 +261,10 @@ Bugs:
   >> would you accept a patch that makes `cgiurl` default to a local
   >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]]
 
   >> would you accept a patch that makes `cgiurl` default to a local
   >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]]
 

+  >>> Yes, I absolutely think it should default to local. (Note that
+  >>> if `absolute()` were implemented as suggested above, it could also
+  >>> be used with cgiurl if necessary.) --[[Joey]]
+

 * It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
   exported? Perhaps also `IkiWiki::baseurl`?
 
 * It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
   exported? Perhaps also `IkiWiki::baseurl`?