On Fri, Aug 09, 2002 at 01:41:46AM +0200, [EMAIL PROTECTED] wrote: > hi, > > here are my comments: > > -detailed information about aggregates: > components not only provide methods, they can hold data as well. > so you might need several components of one type, and you might want > to share them with other aggregated components. so the namespace that > is filled with information like which node a component is one, what is ID > is, ... is just the runtime information, what the programmer wants is a > way to define which componets he actually wants to work with, how he > wants to call the instances, lower/upper bounds for the amount of instances, > and so on. message routing between them. a component designer will want > to specify this because this is the component's world. > one should be able to address components by these component-design names.
Thanks for reading the RFC and especially for commenting on it. Here are my replies. I'll try to incorporate everything into the document tomorrow. First, I misused the term "aggregate" in the original document. It's mostly fixed now. Aggregate components are ones that are created by factories or pools. They are anonymous for most purposes. 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. > -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". > -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. > -message queues should be used for remote links, so at least communication > failures won't matter. This sounds reasonable. > -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? > 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? > 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: 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. 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. POE users should not be required to know UML. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
