- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Fri, 10 Oct 2008 20:29:42 +0100
- To: "Mark Baker" <distobj@acm.org>
- Cc: public-webapps <public-webapps@w3.org>
Hi Mark, On Fri, Oct 10, 2008 at 8:09 PM, Mark Baker <distobj@acm.org> wrote: > On Fri, Oct 10, 2008 at 2:25 PM, Marcos Caceres > <marcosscaceres@gmail.com> wrote: <snip> > That's still a relative reference, so I have no problem with it. > > What I'm asking is whether an author would ever need to use a full URI > to a local part? No, never. <snip> >> The problem with localhost is that you may have Apache or some other >> web server running that you want to interact with (e.g., during >> development testing); In which case, you would have to request >> permission to via the configuration document to access the network >> (localhost). I don't think it would be good to override localhost >> unless the widget engine was actually going to serve content. If the >> widget engine was going to behave like a web server, then yes, by all >> means use localhost. > > Ok, it doesn't really matter from my POV. > > But with regards to my last remaining question to you (above), if the > answer is "No", then I think the answer for the URI scheme is "Any > hierarchical URI scheme". So if one agent wants to internally use > file: and another wants to use ftp:, then they can do so and still > successfully process the same packaged widget. The choice of the URI > scheme is an implementation detail. Ok. I will add "Any hierarchical URI scheme" as the proposed solution into the spec. I will say that, personally, I feel it is irresponsible for the WebApps WG to not recommend a complete and a secure solution for this issue. I also fear that not mandating a URI scheme will lead to interoperability issues (especially going forward into V2, where we might want to support things like queries and fragments, which something like file: does not support). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Friday, 10 October 2008 19:30:25 UTC