Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!USU.BITNET!SLMYQ
From: SLMYQ@USU.BITNET
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPC
Message-ID: <8804140625.AA11723@jade.berkeley.edu>
Date: 14 Apr 88 06:15:00 GMT
Sender: uucp@ucbvax.BERKELEY.EDU
Lines: 77

OK, since this IPC discussion is not really getting anywhere,  it's time to
start defining what we need. Has Usenet EVER finished defining something?
Anyway, this is just an abstraction of what I think we need.

I'm posting this to comp.sys.amiga.tech because THAT'S WHERE IT BELONGS!

I think there should be two basic types of IPC: user-controlled IPC and
program-controlled IPC.

User-controlled IPC

    In user-controlled IPC, the user provides or defines the link between
    processes or tasks. Piping would be considered user-controlled, because
    the user sets up the pipe. The Clipboard would also be user-controlled
    IPC, but indirect - a program first posts something to the clipboard,
    and later another one reads it. They communicate with each other
    through the clipboard, which the user controls.

    These are two good examples of user-controlled IPC already built into
    the Amiga. However, piping has some serious limits (stream-only,
    CLI-only, and mostly text), and the Clipboard is hard to use and
    indirect. We need something that can pass any kind of data,
    including structured data, works *efficiently* with the Workbench, and
    is easy to use for the programmer.

Program-controlled IPC

    This is the kind of IPC that the user doesn't need to know about, such
    as devices, messages and ports, etc. This kind of IPC works between
    two processes - the server and the client. The client calls on the
    server to perform a service. I think there are three forms of major
    services - output, conversion, and input/editing.

    Output

        The printer device could be an example of an output service - it
        outputs data to the printer. A "show picture" service would open a
        screen, display the specified picture, wait for the user to tell it
        that he's done, close the screen, and signal the client.

    Conversion

        Conversion services would convert data from one format to another.
        The Translator would be considered a conversion service - it
        converts from English to phonetics. One "standard" conversion
        service I would like to see is a compression service which
        compresses or decompresses data in a variety of ways, like
        run-length and Lempel-Ziv encoding.

    Editing

        Most applications would go into the input/editing category. A
        painting program would be a "picture editor", and a music program
        would be a "music editor". Their service to the client would be to
        let the user edit something under the client's supervision.

        Although this may seem quite useless, consider this. Many people,
        including me, are against compilers including integrated editors.
        I prefer to use my own favorite editor than be confined to the
        limits the compiler's editor imposes. The good thing about
        integrated editors is that the compiler "controls" the editor, so
        it can bring up the editor at a certain line, saying "Syntax
        error", and the user would know exactly where the problem was.
        Certain keys could be defined in the compiler's interest, for
        example, a "next-error" key. Same with menus. If we carefully
        define this kind of IPC, we can create very flexible environments
        for the user. Obviously, text editors would have the biggest job in
        this category, but that doesn't mean other editors wouldn't want
        IPC. For example, an animation system might want to have IPC so
        specific external programs can create special effects, such as
        neato explosions or fractal animation.

Anyway, this is just a big jumble of ideas, and you won't find a single
drop of code or structure definitions here. I'm just trying to define the
various uses for IPC. We'll have to mess with it a bit, and maybe we can
come up with something useful.

                                Bryan Ford (SLMYQ@USU.BITNET)