On Fri, Aug 09, 2002 at 08:30:00AM -0400, Richard Soderberg wrote: > On Friday, August 9, 2002, at 07:42 AM, [EMAIL PROTECTED] > wrote: > > > What I meant was something different. A directory in which components > > can > > publish their services can be helpful, like you said. > > The interfaces I'm talking about are real roles that components claim > > to be > > able to play. So "client" means it can play a client in the way that > > client was declared before (the protocol, which events are sent, ..., > > see > > below). Very similar to the interface that is spoken by the whole > > component, > > as outlined by the Emit: or "> .." "< ..." statements in your examples. > > Which allows components to deregister themselves as necessary -- say, > when you don't have any listeners connected, or if the service isn't > configured, there's no point in being listed as a "music broadcaster" > service (for example).
Just to make that clear, "my" roles are different to Rocco's. :) If I understood him his idea was the same you talk about, where components register the services they offer. IMHO that is probably not needed for non-public programs, as you usually know what's going on and what components can do. Service directories for several people's programs are ahrder to do, especially the proper description of what is offered. See the various approaches that are tried for web services and agent systems (*brrr*). What I was talking about is a design decision, fixed at compile-time. Like the contract that associated with a class in OOP (methods+attributes). torvald
