Besides making the problem harder and adding a level of indirection,
I don't see how talking to a local server is any different. Instead
of figuring out how to encode a command into the URL, you have to figure
out how to encode a command into an application/x-csh content type.
The content type isn't going to be any more portable than the URL
encoding and it may even be harder to do security checks on it.
>My reasoning:
> o Browsers cannot change on a whim, because for the Web to be truly
> useful to the user community at large all browsers must support the
> **same** set of features (to a large extent anyway).
> o Therefore we **must** have a definition for the browser that is simple
> and complete such that any features you might ever want can be done
> in a server.
I'd hardly call executable content types any more supportable by all
browsers than exec: URLs. They're both inherently local things if
you want side effects and that has no effect to the community at
large since they won't see them. Not all the browsers are equal
right now, which is healthy progress in action -- you can't raise the
bar all at once. For that matter, exec: URLs would be more uniform
since they operate at a lower level.
> So why the SAS that seems to be so prevalent? Instead of hacking
> things into the browser we should be looking for ways to extend the
> browser such that servers can do those tasks, but everyone seems to
> be heading the opposite direction. Maybe this is something we
> can take up at the workshop (what should go in the server and what
> should we build-in to the browser).
Servers are not _that_ easy to write. They are if you're running UNIX
and you have either inetd.conf privileges or know how to do sockets.
Who knows what you'd have to do under VMS or MVS and you just can't
do them under MS-DOS. On the other hand, writing a program which
dumps some HTML to a file is easy and possible under all systems.
It's very similar to adding to a server, but anybody, not just the
server administrator can do it and they can share with other non-privileged
users.
Even if you can easily run a server, you've got some security problems
to deal with. Having a browser that will execute code (or URLs, whatever)
from documents is a little scary; having a server that anyone can
connect to execute code is really scary. With the browser executing
code you leverage off the normal system authentication. With a server,
you have to re-invent that. Sure, these features are coming and
that's good; but you're building up an awful lot of stuff to solve
a simple problem.
>I'm not a purist or anything, I think it's fine if we want the browser to
>support things like gopher and ftp directly but at some point we are going
>to have to draw the line if we want most browsers to support a common
>set of features (even <IMG> is a good example of this problem).
Well, if you want to add features you have a choice. Either make it
harder for the browser writers or make it harder for the server writers.
I maintain that the exec: URL scheme makes it a little harder for
the browser writers but is a boon for server writers since it truly
makes it easy to write a server (just like the simple inetd scripts,
but you don't need privilege).