Re: [Vimprobable-users] Improve handling of file parameters
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
From: Hannes S. <ha...@yl...> - 2013-02-25 08:30:47
|
Hi! Morgan Howe <mt...@gm...> wrote: > Apologies for the odd means of responding - I'm not on the list, > please CC me in the future. :) Has it occured to you that it might be much more convenient for everyone involved to simply... subscribe? It's not like this list will send tons of traffic to your inbox. As you can see, there have been a couple of other responses to this thread and it's virtually impossible that everybody will remember to keep the CC in all of them. > > on your command line. Your solution would make it impossible to call > > URLs from a directory which has a file or subdirectory with the same > > name as the URL. E.g. if your file system looks like this: > > . > > .. > > http://www.example.org > > and you call > > vimprobable http://www.example.org > > it will call the local directory instead of the URL. No workaround > > possible. Before someone argues that this is a rather academic > > example, I would like to point out that such a directory structure > > is not so uncommon on machines used for web development. > > > > Yeah, I considered this, though I was thinking that would be a rare > situation. Not being a web developer personally, that may have been a > bit presumptuous. Perhaps it may be better to check if the parameter > is already a URI first, before checking if it is a file? At least > that way, there would always be a workaround in case of name > conflicts. And how would you detect if something is a URL? The only reliable way I can think of would be sending a skeleton HTTP request out to see if there is a response. Which would involve potential failure sources like DNS which are completely outside the scope of the browser itself. What would be the behaviour if the user intends to call a URL, but name resolution temporarily fails? Will the URL string then be passed to local file handling? So that means that if it cannot be found locally either, the error thrown at the user will be 'file not found' instead of 'host name not found' which would be quite confusing. Hannes |