- From: Tim Berners-Lee <notifications@github.com>
- Date: Fri, 12 Feb 2016 05:05:23 -0800
- To: w3ctag/spec-reviews <spec-reviews@noreply.github.com>
- Message-ID: <w3ctag/spec-reviews/issues/76/183317897@github.com>
> On 2016-02 -11, at 19:31, Brian Kardell <notifications@github.com> wrote: > > I'm not trying to add difficulty to this conversation but I'm genuinely still having trouble understanding... > > Specifically, I'm having difficulty discerning what @timbl <https://github.com/timbl> is looking for or commenting on here as I expressed in > https://lists.w3.org/Archives/Public/www-tag/2016Jan/0014.html <https://lists.w3.org/Archives/Public/www-tag/2016Jan/0014.html> and after talking with various people I dont think that I am alone in that. > > In that post I asked some questions to try to clarify and I didn't really get any reply from Tim so despite having further talks with other TAG members I don't feel like I am closer to understanding. > > So maybe it's helpful to more than just me if @timbl <https://github.com/timbl> can tell me where I go off the rails... > > 1) With regard to fetch it is intentionally low level aimed at explaining existing stuff upon which we can build new higher level stuff. > > 2) Many many deployed web rely on XHR's exposure of withCredentials/CORs. Even if everyone agreed it was fundamentally bad we can't just switch it off -- so in order to explain that, fetch has to expose it too. > > 3) Many existing high level things already in the system have enough information to make the right decisions with only a url and do ok things. > Many isn’t enough. Yes, many apps can just leave it on or off, as they only work with public or only work wit authenticate stuff. I am writing libraries, not just apps. Libraries use content = get(uri). Throughout. At many places, in many ways, at different levels. Libraries call libraries. Library code has no idea about what application it is working in. Secure, public, distributed, centralized, localhost, file:// ftp:// http:// …. it just has to work transparently. That is the job of fetch() To add an extra flag is impossible. It breaks so many things. If you still don’t understand and accept this, we should probably have a face-face meeting. You want a “credentials” flag? It has to be in the URI or nowhere. You could add a new part to the URI, as we did with HTTPS. You can redesign the way it works inside, and adapt the wire protocols it uses, but you can’t change its signature. It is the architecture of the web, and the fact that one could design all sorts of cool apsp with an archietcture based on content = get(uri, credsFlag) but that isn’t the web. It is systems where bookmarks and caches and RDF systems have pairs (uri, credsFlag) where currently they No. Maybe you and I need to have a face to face conversation about this. > Once explained, I think several people have expressed that we could do more and that is a separate and bigger concern from fetch exposing with credentials. > > @timbl <https://github.com/timbl> - Did you disagree with any of these? If so, at which point? > > — > Reply to this email directly or view it on GitHub <https://github.com/w3ctag/spec-reviews/issues/76#issuecomment-183125622>. > --- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/spec-reviews/issues/76#issuecomment-183317897
Received on Friday, 12 February 2016 13:05:52 UTC