Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!petro!swrinde!ut-sally!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!ames!decwrl!hplabs!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: Re: IPCMessages -- A Prototype Keywords: IPC, standard, BADGE Message-ID: <6416@well.UUCP> Date: 30 Jun 88 22:57:34 GMT References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6387@well.UUCP> <2213@sugar.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 101 | From: peter@sugar.UUCP (Peter da Silva) [discussion of caching deleted] | > Second, caching makes list searching a rare event. A cache is just a | > pointer to a port plus a flag to indicate if the cache is still valid. | How about adding one more thing to a cache: the object and method it's | a cache on. That way you can use the cache as an "opened" port, and | not have to deal with the rest of the info again. That makes it a lot | less obtrusive. It's actually like that already; I just didn't specify that before. The cache structure I'm using as a strawman is as follows: struct Cache { struct Nod owner_node; struct Nod base_node; struct Server *server; long valid; long class,cmd; } /* Cache structure. A cache contains a pointer to a server and validity * flag. Flag gets set to INVALID whenever anything in the class tree * for this cache changes, so the server pointer will always be marked * appropriately. The cache is also associated with a task, so when the * task closes the library, its caches are freed. */ As you can see, the Cache does contain a reference to the class and cmd (method) codes for this server. You can also find these by following the Server pointer. The function used to apply methods to objects is defined as: long Dispatch(object,cmd,cache) struct Object *object; struct Command *cmd; struct Cache **cache; The Object and Command structs contain the class and cmd (method) codes, respectively, for this request. Note that the combination of object and command uniquely define the server to be used, so no port actually need be referenced explictly. Dispatch() can be called with cache=NULL, and if it is the server and port will be looked up in the service database. If there is a cache, the Dispatch() function checks its validity and if it's good, compares the cached class and cmd codes to those requested. If they match, the cached service port is used immediately. If not, the correct service port is looked up in the database and stored in the cache. Note that if caching is used and the object class and command code are the same on each call to Dispatch(), which is often the case, then the response is very good. Note also that caching is optional, which is consistent with the OOIPC design philosophy -- that is, that you make requests in the form of methods to be applied to objects, not commands sent to ports. The fact that there are ports involved is deliberately obscure. | > want to make your objects network transparent, implement a `SAVE' method | > on them. This allows specific objects to use their own compression | ... | > in-memory bitmap object could have the `SAVE' method write the bitmap | > out as an IFF file. Since this is something that is generally useful, | Good idea. Thanx. | > My main point is that I cannot implement an object-oriented scheme under | > PPIPC as I understand it (at least not efficiently -- a broker with a | > search every time and four context switches doesn't make it), whereas I can | > implement everything that can be done with PPIPC under OOIPC nearly as | > efficiently. | Well, the broker doesn't *have* to be a seperate program, any more than | it does with OOIPC. Like I said, the high-level behaviour of messages is | wide open. Some of the issue is personal preference. It's obvious that some programmers are going to want an IPC mechanism more like PPIPC and some are going to want OOIPC. It's silly to restrict people to using only one paradigm. There may be a way to integrate the two approaches and get the best of both worlds in terms of performance and features. | Tell you what, then. Implement a demo OOIPC system and let's play with | it. Submit it to alt.sources.amiga... Funny you should suggest that... In fact, I'm writing such a beast right now. I've been thinking about the design so long that the actual coding is going very fast. Although the full-blown system is a little elaborate, there are reasonable places I can short-cut to get things working quickly. The real test, of course, is to build some demo applications and see how it works. Side note: Is there any way to use SDB when writing a shared library? Curiously enough, I found that my original spec for standard messages and objects may not be sufficient, and the result of the redesign is starting to look a little like IPCMessages. Highly simplified, with only 2 flag bits instead of 7 or 8, but its ancestry is clearly evident. :-) -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)