Re: HTTP status code equivalents for file:// operations - compat with xhr

On Tue, 18 Aug 2009 15:09:53 -0400, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Aug 18, 2009 at 12:03 PM, Michael A. Puls
> II<shadow2531@gmail.com> wrote:
>> O.K. Thanks. fileadata: wouldn't work then if the user has to choose the
>> file.
>
> Maybe it would help if you started with a use case. What type of thing
> are you trying to build?
>
> Many times when people deal with file:// urls it is because they are
> building a website on a local file system, and then at appropriate
> times publish that website by copying the local files to a web server.

I support that convenience (when dealing with static files) very much.  
(And, I don't think think this use case should be dismissed, just in case  
anyone thinks that.)

> Is that what you are doing?

A lot of times, yes. I believe things should work the same between http:  
and file: in static (not php etc. of course) cases. They basically do with  
DOM3 Load and Save.

> Or is there another reason you end up
> using file:// urls?

Yes, one thing I'm doing is loading a local xspf file from a local web  
page (via a script) and parsing it into an ordered list with registered  
listeners. This page isn't meant to be published on http (but it should  
work just the same).

I can do that now with XHR, but it's a mess and error handling isn't good  
enough, nor is it interoperable. DOM3 L&S would be nice, but no one wants  
to support it.

Basically, I'm looking for an API that actually supports local, static,  
web-based apps instead of trying to force it into APIs that don't. That's  
why I also proposed  
<http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0680.html>,  
just in case the simulating HTTP status code idea wasn't taken well.

I don't believe a local server should be needed in this case when there's  
already a file system to work with.

I wasn't worried about any of this as I thought Firefox, Safari and IE  
were going to eventually support DOM3 L&S and that Opera was going to  
improve their implementation. But, the feedback I've seen on this list and  
the Mozilla bug reports seems to say otherwise. So, I'm hoping for an  
alternative to DOM3L&S that's simpler so vendors will implement it.

Hope that helps and thanks.

-- 
Michael

Received on Tuesday, 18 August 2009 19:40:15 UTC