Would probably be better if this were generic enough that all clients
could use it. Actually, since we're talking about commuication
between applications, it may not be portable to MS-Windows or Macs but
at least we can make it UNIX portable.
> News Browsers: A full function news browser needs to have
> history file. The history file would then be used to prune the
> article list (typically a UL list) to hide what one has already seen.
> Additionally, one would like to be able to have kill files, search
> functions, reply and post functions, etc.
I guess I'd see this as an area where the existing news: URLs could
work OK, but news browsers need some mechanism for having another
program tell them to go someplace.
>Outline of Proposal
>
>I would like to suggest a simple modification of the viewer mechanism,
>so that we could have a tool in-between the two above mentioned
>extreme choices. That is, I am proposing something I call Accessories.
Something like this sounds reasonable.
>Maintaining a communication channel between application components
>is an important part of both of these systems. With Applets, one uses
>OLE to invoke and communicate information, while in TK/TCL one
>uses the send mechanism (via the X11 property lists, or in TCL-DP via
>TCP/IP).
>
>This model of software, where compound applications are fabricated
>out of a flock of inter-communicating sub-application tools, is also
>becoming in vogue in the CORBA community.
Ah, so many approaches to choose from... presumably what has to happen
is that someone picks one of them and implements "standard" and
(hopefully) portable stubs for both the browser and the accessory,
maybe smart enough to use something ICCCM based where available and
pipes or sockets otherwise, or something like that. There will be
lots of accessories and lots of browsers, and the details of which
talk to which how need to be abstracted out.
>Invocation of Accessories
>
>Applications can be thought of as client side CGI scripts. Thus a
>rudimentary way of implementing accessory invocation would be:
>
> <A AREF=accessory.ext>Generic Accessory</A>
>
>However, one would prefer not to specify an actual file, but rather a
>MIME type which would then be mapped via the .mailcap file to the
>accessory. This would allow one to create documents that specify a
>generic type of accessory, and allow the user (via the .mailcap) to
>choose the version of the accessory that he/she wishes:
>
> <A AREF=accessory/x-html-editor>HTML Editor</A>
>
>The .mailcap entry for this could be:
>
> accessory/x-html-editor HTML-ED.exe
I guess I don't get what exactly would be in the file "accessory.ext"
that would be of type "accessory/x-html-editor". More abstractly, I
don't see how anything except the program itself can be an object of
that type. Though there should be consistent names for these if
things are done this way, I don't really think MIME content-types are
suited to this. What would it mean if I mailed you a message with
this content-type? What would go in the body?
Anyway, generally I like the paradigm; it's somewhat bigger than the
discussion of client-side programmatic languages like Safe-Tcl (a
safe-tcl interpreter, running server-provided code, would be one
potentially very flexible accessory.)
- Marc
-- Marc VanHeyningen [email protected] MIME, RIPEM & HTTP spoken here