I agree.
> Several solutions have been suggested:
>
> 1. The browser becomes a sort of pseudo window manager, reparenting
> the windows of external viewers.
I'm not sure what you're thinking of here. You're refering to a
technique, not to an architecture. To me, it might be something like
the WWWinda project, where the browser side becomes a set of
un-centralized cooperating agents, one doing HTML, one doing GIF, one
doing video, etc.
> 2. Browser and viewers communicate with a special embedding protocol
> that is an extension of the X protocol (compare OLE under MS
> Windows), as in Jan Newmarch's work:
> <http://pandonia.canberra.edu.au/SW.html#embed>.
Jan's work was done while he was a sabbatical at the OSF (and while I
still was working there).
It's not an extension of the X Protocol, which is something that has a
very specific meaning (like PEX, DPS, XIE, etc), it's done in way that
reuse X component, like the new R6 Session Management work, and some
new widgets.
> 3. Viewers are not written as complete programs, but as modules to
> link (dynamically) to a browser, as in my W3A:
> <http://www.let.rug.nl/~bert/W3A/W3A.html>.
I just don't like relying on dynamic linking, which is still an OS
dependent feature.
> 4. Viewers are written in a special embedded language for which the
> browser has an interpreter (just like Emacs is extended with
> programs in e-lisp).
Or maybe this is the WWWinda stuff in your mind ?
>
> In (1) and (2) additional protocol has to be specified, in order to
> allow the browser and viewer to exchange commands. Currently, I have a
> slight preference for (4), since it makes viewers portable to other
> platforms.
I personally prefer 2 over 1 and 4 (whether it is OLE, OpenDoc or
something more X specific like Jan's), in part because I'm afraid
something like WWWinda might be too radical a change in architecture.