> > What i was getting at is that the way they talk should be decoupled > from the hosting environment so we avoid the problems we've had in the > past such as a sample configured to use port 8085 as part of the build > then doesn't work out-of-the box when people try to use it on port > 8080.
I agree that we would like to see a lot of our samples using binding.sca and that that should be as flexible as possible, However we can't exclusively rely on binding.sca and will have to configure binding.ws, binding.http etc. In these latter cases we can't disregard the hosting environment. As we are going to have to have some configuration for a node I'd rather it was all in one place so it's obvious what the user has to configure. > > And, its looking likely to me that the endpoint registry and sca > binding can be closely tied together, for example there doesn't seem a > whole lot of point in wanting a WS based sca binding for > network/firewall reasons if the endpoint registry is using multicast > so wont work across that firewall. I agree, if you adopt one approach for one part you would assume it's going to work for another. I would though treat something like tribes as a transport. That means you can still run SOAP over it if appropriate.The endpoint ceases to be something you derive a direct physical address from but supplies the name of the member in the group that supports the service (the node) and then the name of the component/service at that node. Most of that info comes from the wiring and some of it (node info) would have to be added to the endpoint structure (has been suggested before). The logical configured root for the binding.sca uri could be the info that is used so set up tribes. I've not played with it so I don't know precisely what info is required. So, in summary, I think this cuts both ways. You would like a binding.sca that exploits a non HTTP transport. I'd like an endpoint registry that exploits an HTTP transport. Doesn't mean either one is invalid. But it would be good if we could use the same configuration mechanism to support both. > > Before i go further, do you agree with all that? > > ...ant >
