The major distinction here should one of action-domain constraints;
1. The filesystem browsing tool should be able to uniquely identify and act
upon requests made to it, and the web browsing tool should have the same
ability; poorly-designed or poorly-implemented name spaces will lead to
collisions, and will require context-based patches to compensate for; those
are bound to fail at the perimeters, as not all interaction scenarios
can/will be anticipated, especially as new domains interweave with these
two to muddy the field some more.
2. Similarly, request sources should be equally constrained; external
sources should have no ability whatsoever to unboundedly act on local
resources; this has been a frequent failing of the various IE implementations.
As we are limited by the fact that the shoddy name space is now prevalent,
then context needs to be taken into account. As one types in a URL without
specifying the underlying protocol (http:// or file://), there should be no
ambiguity that the expected protocol is http, just as we do not naturally
expect file system requests to be carried over the web. The fix is in
filling-in missing protocol details, within logical usage contexts, before
the request allocator gets a chance to goof it up.
Cheers,
+ Louis-Eric Simard
The Freedom Factory, Inc.
At 05:05 PM 11/08/2001 -0700, David Schwartz wrote:
> > David Schwartz wrote:
>
> > >>The browser should not be the file manager. That is all there is to it.
> > >>-b
>
> > > Sure, and the OS shouldn't be the memory manager. The
> > >filesystem should be
> > >purchased separately. And you should need a separate client for FTP. Your
> > >network stack should come from a different vendor than your OS. And your
> > >computer shouldn't include memory. I vote for maximum inefficiency and
> > >duplication of code too.
>
> > > Why should viewing a remote resource be any different from
> > >viewing a local
> > >resource? Especially when you consider that local files can
> > contain diverse
> > >content types requiring complex presentation and navigation -- just like
> > >remote files.
>
> > > DS
>
> > You are missing the point. You can view resources both locally and
> > remote and I have no heartburn. However, viewing and managing are two
> > entirely different concepts. A file MANAGER, by definition, MANAGES
> > files. A web BROWSER, also by definition, BROWSES the web.
>
> No, you are missing the point. How can you manage files if you
> can't see
>their contents? How can you view files through the FTP protocol if you can't
>navigate directories?
>
> It is illogical to have one tool for each protocol. When I want
> to view a
>resource, why should I have to think about whether it's a local text file or
>a JPG that has to be FTPd? I want one interface. What you are asking for is
>a browser to be just an HTTP tool, and that's a mistake. FTP is a protocol
>too. And there's no difference between a file I can FTP and a file on my
>local hard drive. There's no difference between what I might want to do with
>a file on my hard drive or a file on a web site that I manage.
>
> > Managing includes operations such as move, copy, delete, execute, etc.
> > Viewing includes none of those operations.
>
> You are ignoring the significant areas of overlap, including
> directory
>listing, retrieving files, and presenting them. HTTP even has support for
>putting files on the web server directly, though this not commonly used.
>Integration between HTTP and FTP makes more sense, and is often a very good
>way to manage a web site.
>
> > If you don't believe me, tell me this. When was the last time you
> > visited http://www.microsoft.com with your web BROWSER and MANAGED the
> > web pages you found there by moving, renaming and deleting them?
>
> Try ftp://ftp.microsoft.com, where you might need to list files,
> navigate
>directories, and who knows what else. If you maintain the site, you may well
>need to move, rename, and delete them.
>
> Information is information, and where it is and what protocol you
> use to
>get to it has nothing to do with how you view it, present it, or even manage
>it. Tools work best when humans don't have to think about protocols. In
>fact, the company I work for makes tools that allow you to do things like
>FTP your mail, view a web site's hierarchy through an NNTP client, or use
>your browser to traverse a directory hierarchy and manage it.
>
> The idea is that information is information, and protocols are
> ways to get
>to information or get information to you. But what protocol you use to get
>or view information has nothing to do with what the information is. And,
>like it or not, a browser (extended through Java and JavaScript) seems to be
>a great tool for doing pretty much anything.
>
> You can make an argument that this type of extension shouldn't
> take place
>until the security issues can be properly dealt with. But you would have to
>be crazy to argue that it shouldn't take place at all. (Unless you think
>some new super-tool will obsolete the browser.)
>
> DS
This archive was generated by hypermail 2b30 : Sun Aug 12 2001 - 21:37:36 PDT