peter@nuchat.UUCP (Peter da Silva) (03/13/88)
Well, there have been some good ideas out there...
Still using the Browser as the technology demonstrator...
struct IPCEntry {
ULONG IE_Id; /* name of this entry */
void *IE_Ptr; /* this entry's data */
};
struct IPCMessage {
struct Message IPC_Message; /* ln_Name == tool name */
ULONG IPC_Status; /* Return status */
ULONG IPC_Type; /* Identify this message type */
ULONG IPC_Entries; /* Number of IPC entries */
struct IPCEntry IPC_Data[]; /* Entries */
};
struct IPCPort should probably be the reference-counted port that Matt
Dillon described. It's a LOT safer than the current ports, and a LOT cleaner
than the various message-broker setups floating around.
All messages are replied to using ReplyMsg(). Any pointers in the structure
rendered invalid by the program should be zeroed out before replying. This
means Freed memory or locks, or even just stuff that you intend to keep
around and delete later. The program that sent the original message should
keep this in mind when cleaning up.
Specific browser info:
Name = BRWS;
Entries defined by this Server:
Id = FILE
Ptr = struct IE_File {
ULONG DirLock;
char *FileName;
};
Id = PORT
Ptr = struct MsgPort *;
Id = WNDW
Ptr = struct Window *;
Id = CSTR
Ptr = char *; /* points to a 'C' type string */
Messages defined by this Server:
Type = ADDF, 1 Entry: FILE;
Browser check to see if it's got that
particular directory locked, and if so
it goes ahead and adds that file to its
window;
Type = DELF, 1 Entry: FILE;
Like ADDF, but deletes that file from
the window;
Type = ADDT, 2 Entries: CSTR, PORT;
Adds entry to Tools menu. Name is taken
from CSTR. When that entry is selected
Browser will send an IPCMessage containing
the files selected in FILE format.
Type = DELT, 1 Entry: PORT;
Deletes all entries from Tools menu using
that PORT.
Type = DELT, 2 Entries: CSTR, PORT;
Deletes the entry from the Tools menu that
matches that string and port.
Type = ADDW, 2 Entries: WNDW, PORT;
Adds that window to its "copy" list. When the
user drops files in that window they will be
sent to the program in an IPCMessage containing
the files selected in FILE format.
Type = DELW, 1 Entry: PORT;
Deletes all windows from the "copy" list using
that PORT.
Type = DELW, 2 Entries: WNDW, PORT;
Deletes the entry from the "copy" list that
matches that window and port.
I guess the FILE entries could be handled as paired LOCK and
CSTR entries, but it's used often enough that it's worthwhile
doing it here.
Note the DELW and DELT entries have two forms available. This
is a side-effect of the format.
Browser will not keep any of the FILE entries passed in ADDF or DELF.
It will zero out the CSTR, WNDW, and PORT entries in ADDT and ADDW, but
not in DELT or DELW.
--
-- a clone of Peter (have you hugged your wolf today) da Silva `-_-'
-- normally ...!hoptoad!academ!uhnix1!sugar!peter U
-- Disclaimer: These aren't mere opinions... these are *values*.peter@nuchat.UUCP (Peter da Silva) (03/13/88)
Second thoughts (talking to myself): In article <783@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > Id = FILE > Ptr = struct IE_File { > ULONG DirLock; > char *FileName; > }; Id = LOCK; Ptr = ULONG; ---------- > Type = ADDF, 1 Entry: FILE; > Browser check to see if it's got that > particular directory locked, and if so > it goes ahead and adds that file to its > window; Type = ADDF, 2 Entries: LOCK, CSTR; As ADDF above, but an alternate method for programs that like to keep their locks seperate; ---------- > Type = DELF, 1 Entry: FILE; > Like ADDF, but deletes that file from > the window; Type = DELF, 2 Entries: LOCK, CSTR; Again, an alternate form. ---------- > I guess the FILE entries could be handled as paired LOCK and > CSTR entries, but it's used often enough that it's worthwhile > doing it here. Browser will accept entries in this format for the ADDF and DELF messages. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.