On Fri, Aug 09, 2002 at 03:18:55AM -0400, Rocco Caputo wrote: > The issue then becomes: How do specific instances of these anonymous, > dynamic components communicate with each other? > > The difficult part of this problem is specifying the path for messages > to travel. How do you link an instance of component X to an instance > of component Y if neither instance exists at design time? > > The current documentation assumes that one of the components has > triggered the other's construction. For example, Component X has sent > a message to a Class Y Factory requesting a new instance. The factory > will notify Component X when a new Component Y is created, and it will > pass the new Y component's ID along. > > Torvald's issue seems more subtle. Components X and Y have been > created by some other means. How then do we introduce each to the > other? The simplest way seems to be for some outside force-- perhaps > the component that created both X and Y-- to tell each about the > other.
Yeah this should be the way to go. Basically because X and Y don't know about each other, and they don't need to. > > > -the component address consisting of node/klernel/id should be just the > > physical name, nothing the programmer has to deal with. this belongs > > in some kind of deplyment description and might change according to > > system load, node failures, ... > > that's why i think that components should talk to the components that > > they were build to talk to, in the component's _local_ words. that means > > that by declaring the events that are consumed/produced an interface is > > defined. but this is not enough, as there is just one interface per > > comp. and there is no information about who the comp. talks to. > > adding something like: > > talks to 1-200 components that have the client interface > > talks to 1 comp. that has the boss interface > > should help. > > This sounds like role-based addressing, which I seem to have omitted. > The idea is for each component to advertise its role in the overall > system. > > "I am a host resolver." > "I am a web client." > "I am a console interface." > > but in a way that is also readable by Perl. When a component needs a > host resolved, it could post its request to the role of "host > resolver" rather than any specific component. > > Comparing interfaces is not enough. In your example, you say "talks > to 1-200 components that have the client interface". There may be > many components that share a client interface, but each performing > some variation on it. > > Perhaps a role is just a specific enough interface. "pop3 client" > instead of simply "client". Or do you mean that the combination of an > interface and some data within the component determines its role? For > example: "pop3 client connected to pobox.com". 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. It's sufficient for our component that it knows that there will be other components which understand the client interface. it can handle 1 to 200 instances. It doesn't matter if these do more, our component just want's to be understood. And that was all the component's designer had in mind. > > > -group events into interfaces. > > declare interfaces somewhere else. results in less typing and easier > > reading. enables the above (that goes in the direction of object > > associations, there is some entry about that on the wiki iirc) > > i just read that you had this at the end of the document, but try to > > associate the interface to the component that is talked to, and just let > > the component support several interfaces. > > Furthermore, you can build composite components which incorporate > other components and their interfaces. Speak up if there's a better > way. > > > -schemas for interfaces: > > it would be fine if one could attach assertions, simple checks, ... > > to interfaces that would make sure the interface is used correctly. > > most comp.s will talk in proabably easy protocols with each other. > > I added some notes yesterday afternoon about this. Interfaces may > include verifiable version numbers. If one component detects a bad > version number, it may decide the interface isn't compatible. > > Another way to do this is, as you said earlier, to compare interfaces. > If message signatures do not match method signatures, then there is a > problem: the components aren't speaking the same language. What I tried to say that the interfaces could be a good place to check that the components stick to the protocol that is associated with an interface. For example, "initialize" events should be sent before "do_work". However this is not really needed but just useful to catch misbehaviour. > > -sharing of components, load balancing: > > if components _only_ rely on msgs sent to them (it's their only input) > > then having to identical copies is just a matter of sending the same > > msgs to them. you will probably need to think about some sort of > > synchronisation, as events might take longer on one remote link than on the > > other. > > Is there a simple, real-world example of this problem? A simple one is that events must arrive in order. The "do_work" event should arrive before the "cancel_work" event (let's assume it was sent this way :). if the events travel across several nodes (for example routing was changed due to network or system load) they will need more time on one route. This will not happen in small programs, since their simple design won't make these scenarios possible. But if we have distributed applications we have to think about these issues. Arthur's question towards transaction support would be the real, big solution. It would be really cool to support transactions, and if you have full control about the input that goes into components you can do rollback, make snapshots, all these fine things (and it is transparent to the component! :). But I doubt that this is really needed and that we have the time to code that. You said (or at least I read it this way, correct me if I'm wrong) that POE apps should be small or mid-sized. There is overhead if you want to support transactions (using them could need less work). On the other hand, if we can control the component's input, and if it doesn't do anything hidden or not repeatable, implementing it shouldn't be that much work (depends on the kind of distributedness). Granularity would be on the component level, performance could suffer from this. It could be on component attribute level if usage of accessors is enforced. Anyway, the question is if people will want this or if it is easier for them to use protocols that avoid the need for transactions, atomic operations, and the like. > > > after all, if you find some time, please have a look at UML. it was > > started by Rationale and is now "developed" by the OMG (the ones that make > > CORBA spec if i got that right...). even if you don't like CORBA :) > > > > http://www.omg.org/uml/ tutorials, introductions etc. can be found in > > your favourite search engine or library > > I keep looking at UML, but nothing on the web has made much of an > impression with me. Is there a good book about UML? Is there a good, > free UML designer that doesn't require Java? Well I learned about it in university courses, but they're in german ... :) Maybe I'll find a good tutorial that deals with the relevant parts... A good tool is ArgoUML: http://argouml.tigris.org/ BSD License, but it is in Java. But that shouldn't be something bad, coding GUI's in Java is much easier than in Perl, I think. There are binaries available and Debian packages exist as well. > > > it is a modelling language that for the same domain: model objects(components), > > what they consist of, how they are related to each other, how they talk > > to each other. a lot of skilled people are working on and with this. we > > don't really need to reinvent the wheel. even if we just use a subset or > > use their terms, it will be a lot more familiar to several people. and > > they already have solutions for several of the modelling problems (syntax+ > > semantices) a POE object layer has to face. > > > > of course there would be the need for some tweaks, POE doesn't have real calls > > (post() is used), stuff like that. but you could use the UML tools, > > tell people that they can model their Perl app in UML, ... > > that would attract a significant amount of people i think. > > While UML is probably useful, it seems vastly more than necessary. I > have considered it multiple times and decided against it for a few > reasons: It is more than we need, especially all the prototypes. What we can use are class diagrams. Sequence diagrams are generally useful. State diagrams are normal state machine notations with some concurrency handling. Have a look at the screenshot on ArgoUML's front page. The notation used in the diagram has about half of the symbols most people will need (or 3/4, interfaces missing). > > There does not seem to be a suitable UML design too. A suitable tool > should be written in C, C++, or Perl; it should be free, and it should > be a fairly complete implementation. C and C++ are portable, but the GUI toolkits are probably not. Same with Perl. So Java seems to be the better choice. You can create simple UML diagrams with other, less specialized tools like dia. There is a standard about how to save UML diagrams in XML files, but I don't know how tightly the tools stick to it. But it's XML so it should be possible. > > None of its diagrams seem to fit POE. Rather, it seems that one must > draw multiple diagrams to write a program. That's great for enormous > CASE-built projects, but it does not allow people to quickly put > together small programs. Well it's about modelling. You don't need to use a diagram, you can just implement the related functions. What we can really use are class diagrams. They already have a notation and well defined semantics for the most of the things we are talking about here. POE Components and objects have the same properties. UML class diagrams have notations for inheritance, aggregating other objects, associations between objects, object-local role names whith which one can address connected objects, ... > POE users should not be required to know UML. POE users don't need to know UML. I don't know a lot about UML neither, and one doesn't have to. It's like using design patterns: people will know about the singleton concept before they know that a lot of other people call it singleton. Users will have to learn POE notations. Why not use the same vocabulary and concepts from something that is know to work and that a lot of people already know? To somebody new to POE the POE notation will always be new. The chance that he knew about some UML-bits before is higher. That's the point, concept and vocabulary reuse. The chance that users will be attracted is just higher. If you take a look at the front page's diagram again: The polygon class has an Polygon() method and aggregates 1 to infinite Points, which the polygon calls vertices. The point class attributes x and y, for which accessors might be created. That's what most people will need. And I think that this is quite simple. There is a lot of stuff targeted at the enormous CASE-built projects, but it works good without that. If you don't want to provide a model of a class, you just leave it out or say "this is class xyz, nothing know about it". Tools might show warnings or don't like this, but the model itself is sound without this information. The class hasn't be specified, but you can treat is as existing anyway. One could express the example in the Wiki in an UML diagram if that would help express the similarities (could be a bit tricky however as the POE notation semantics are a bit vague sometimes). The same objects/components are specified. You cannot specify msg routing to sub-components in class diagrams, but one can express it in sequence diagrams, for example (they specify which messages/events are sent between objects, and in which order). The ArgoUML manual has some information about UML as well I think, but I haven't seen it before. I will take a look at it. torvald
