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. -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. -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. -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. -message queues should be used for remote links, so at least communication failures won't matter. -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. 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 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. torvald
