Re: Impending web-arch issue?

Anne van Kesteren wrote:
> On Tue, 11 May 2010 10:32:44 +0200, Nathan <nathan@webr3.org> wrote:
>> In light of all that's been discussed, would you agree that neither 
>> approach is ideal, and that the current closed xhr web approach 
>> (whilst it keeps things safe in the interim) isn't a long-term fix 
>> that addresses both issues?
> 
> I don't think your issue is critical. It can be worked around easily 
> with a proxy. And most applications will have some kind of server 
> component that can do the requests on behalf of the application.

the issue introduced by adding in a server side proxy:
"yet the whole point of making a purely client side application is so 
that it doesn't need a server and uses the web as a distributed data 
tier.. not to mention http cache'ing and bandwidth issues, it creates a 
silo, a bottleneck where the app can't scale, adds in a layer where all 
a users data in-out can be monitored and collected, more.. there are 
many implications to this."

also: client side certificates for use over HTTPS for WebAccessControl 
can't be send through a proxy - UA must interact with the resource directly.

>> As noted the same issue(s) will arise again with browser extensions in 
>> the near future. Thus, can we open CORS+same origin policy for XHR up 
>> to a round of suggestions that keep the web both safe and open at the 
>> same time? - or at least make it a bit easier to open up by adding 
>> default CORS settings for an entire domain in a .well-known place or 
>> suchlike.
> 
> That has too much potential for problems. This was discussed at length 
> in the past already.

any response to the question "Thus, can we open CORS+same origin policy 
for XHR up to a round of suggestions that keep the web both safe and 
open at the same time?" - or is that what you were responding to??

>> IMHO universal browser based client side applications running over a 
>> web of data is a huge thing for the web to loose, and something I 
>> wouldn't like to see given up, especially with the advent of HTML5+JS 
>> APIs - all the pieces are in place, the web is shifting in this 
>> direction - and afaict this issue is the only thing blocking us from 
>> progressing.
> 
> It doesn't really see to be blocking us too much. Web-based feed readers 
> etc. have been prevalent for a long time.

short, again: nobody can make a client side web application that runs in 
a web browser and uses data from the web. (unless everybody with data on 
the web in adds on CORS headers to every resource they own allowing access).

note: not a client side UI for a server side web application, no server 
side involved; web as data tier / provider - see web of data, linked 
data, open data, rdfa, open graph, microformats etc.

please do see the original post which described the problem at length, 
and TimBL's later reply acknowledging the problem and pointing to Jim 
Hollenbach who's hit the same problem, and then pretty much every post 
since describing and going through the problem + approaches.

Regards,

Nathan

Received on Tuesday, 11 May 2010 11:24:36 UTC