But this is not really the same thing. These projects are (for the most
part) sponsored and controlled by individual groups --- not some coordinated
large effort. It's like saying the contributed software in X is more complex
than the X server or the Linux kernel. This is not true. Indeed, the
aggregate of all of the contributed X packages is *a lot* of code. But
because they are all independent projects with little interaction, the
complexity is containable.
I want to preserve the current Web model of lot's of people developing tools
in all sorts of places with loose coupling between them.
> The trick is to have an interface specification so that people can implement
> small bits without having to wory about all the other bits.
I agree.
> If I want to link to a new-and-wizzy format that holds, say, five channels of
> floating point colour data from a satellite I just need to implement a viewer
> for that type and declare a MIME type. Everything else works fine with it.
Now what if I want to embed that new-and-wizzy format into my document so
that I can flow text around it, or make it a hyper-reference, or simply make
it go away when I switch pages? The current external viewer approach breaks
down! We need better integration.
> If I want to make my server use an automated English-to-French translator on all
> files before sending them to clients in .fr domain, again there are selected
> bits of the server to alter, I don't need to re implement the whole thing from
> scratch.
Servers are in a better position than browsers right now. The transparent
invocation of server scripts enables this. Browsers are *much* more
monolithic than servers. (An aside to tkWWW users: have you experimented
with a Tk document (register a new MIME type) that you read in an IMG tag
and dynamically load and run?)
> Chimera extends this idea by devolving _all_graphics rendering onto external
> apps. So to do an inline GIF, have the GIF viewer render into a pixmap or an
> area of the main window that you give it. Suddenly, having any type of graphics
> inline becomes possible without additional effort.
Chimera is ahead of the game then --- I believe that the emacs browser does
something similar. But this is still browser dependent (I can't write one
external rendering agent and expect it to work against a whole class of
browsers) and it still only works for *some* things. What happens in
equation, table and form rendering for example? How about embedding
*dynamic* objects --- like an interactive game?
> So the ideal is to have a flock of communicating applets, all providing some
> service or other, and the browser as such is just the glue that synchronises and
> coordinates this flock. Any applet can be enhanced without impacting the others.
>
> I believe Dave Raggetts browser is designed this way.
This is exactly my point. Let's simplify HTML+ by standardizing the "flock
of communicating applets."
> > >The
> > >only people in a position to implement a monolithic browser are those with
> > >dedicated (and large) programming staffs --- such as Framemaker or Microsoft.
>
> OK then, I will agree with you. But the last thing we want is a monolithic
> browser, so that ceases to be a problem.
Let's not have a monolithic HTML+ standard then...
> It also removes the problem that once some large monolithic company got hold of
> the Web the first thing they would do would be to introduce subtle
> incompatibilities so that their payware version gave you an advantage, and so
> you were locked into their 6 monthly upgrade payment cycle. This is just based
> on past experience of companies like these. Ask anyone how well the RTF standard
> fares each time Microsoft upgrade their products. Its just easier, all round, to
> only use Microsoft products - use Word to generate it, use their help compiler
> to process it. So simple, all you have to do is pay them and trust them. No
> thanks.
I hate this possible future as much as you do. Why do you think that this is
such an unlikely future? Let's create an interesting browser/rendering
market where "best of class" tool integration is designed into the
architecture.
> One of the stongest consensuses (consensi??) to come out of WWW94 was the
> universal dread of what would happen when Microsoft noticed the Web. To be fair,
> I think that particular company was being used as an archetype of the general
> class of commercial companies.
It's not going to be possible to prevent the commercialization of Web tools.
I *want* a large variety of Web tools --- both free and commercial --- to be
available. The only way I know to prevent monolithic tools and big vendors
from dominating the market is to design in, at the most basic level, a
modular architecture.
> > The situation changes radically as software becomes simpler. If you look at
> > text editors or small languages the number and variety of free applications
> > is enormous.
>
> I agree completely, which is why the current situation of Web design by
> consensus among people interested in the Web is the best bet. Hardly a week goes
> by without some new, small improvement in one area or another. As the interfaces
> become better defined, this process will accelerate. Hey folks, I knocked up an
> improved HTML 3.0 table renderer, works with all compliant browsers. Do you see
> some huge corporation coming out with statements like that? No.
No, but I do see some corporation modifying their desktop-publishing tools so
that they "do" HTML+. Then those become popular, the applet market goes away
and the Web becomes a boring place to live (for a programmer... :-)
> <aside>
> For a laugh, try telling Frame (just to show I am not singling out Microsoft
> unduly) that you really need multi page footnote handling and could they
> implement it soon please. If you need to understand this joke, try scanning the
> framers list and see how far back those requests have been coming.)
> </aside>
What a lead-in! This is exactly one of the things I want to see allowed ---
you just defined a new tag (on the fly I suppose.) Why not allow the tag to
be formally defined in the document header and associated with some external
rendering tool --- maybe even where to get a copy of it if the user doesn't
already have it? Then a browser can just save up all the data and pass it
off to the renderer. HTML could be trivially extended in this manner to
experiment with different ideas. There's a lot more to this than what I just
said --- but we first need to see that a monolithic HTML+ is not going to
help us.
> >If I apply this reasoning to HTML+, then there must be some point at which a
> >browser becomes so complex that very few people are willing (or able?) to
> >implement one.
>
> Implement one, no. Implement bits, yes.
How do I know that my bit works with someone else's bit? Interoperability
is key. Otherwise all we have is a giant bucket of bits. :-)
> >Web browsers
> >will start to look an awful lot like desktop-publishing applications.
>
> Yup.
>
> > How
> >many freely available desktop publishing tools do you know?
>
> None worth a damn. Yet.
You know someone working on one? If that's the case then how much
competition is it going to get after it's released? Probably none! That's
because of the enormous investment in creating one. It will essentially
become the de facto "free" desktop publishing standard --- and if someone
wants to experiment with different interfaces and ideas, they may have to
start from scratch --- or just forget about trying them out.
> >Who dominates the desktop-publishing market? How easy is it to make a
> >desktop-publishing application?
>
> How easy is it to get them to respond to user demands? How many users are locked
> into proprietary solutions and forced to pay top whack because the cost of
> moving to another proprietary solution is too great?
And why do users live with this situation? Because they can't negotiate
from a position of strength! Vendors know that users have an investment in
documents, training, software, etc. If vendors knew that a user could rip
out the table formatting code and put in something they like more, vendors
would radically change their ways.
> >Who controls the desktop-publishing document format standard?
>
> Which standard was that, again?
My point exactly... :-) When the market is dominated by a few key players
then standards get trampled on. Isn't MS-DOS a great standard? Isn't
MS-Windows a great standard? Isn't Rich Text Format a great standard? No,
of course not, these are all lousy standards. We never know what part of
the standard is going to change. We are *barely* able to influence it. We
*know* that if a different vendor is somehow able to make something
compatible there will be gratuitous changes to prevent competition. People
are dreaming if they think just because some big vendor starts with an HTML
compliant browser that they are going to stay that way! Look how much Mosaic
has changed HTML. We're just *damn lucky* that it was the NCSA that invented
Mosaic and not Microsoft.
Wow. That's a twist I never thought of before.
> The point about the increasing complexity of the raft of software collectively
> implementing the Web is well taken. But the solutions are already in hand, using
> the long established software engineering practice of modularity.
If someone can demonstrate this to me I'd feel a whole lot more comfortable
about the future.
- Ken
-- Ken Fox, fox@pt0204.pto.ford.com, (313)59-44794 ------------------------------------------------------------------------- Ford Motor Company, Powertrain | "Is this some sort of trick question CAD/CAM/CAE Process Integration | or what?" -- Calvin AP Environment Section |