|RE: [ecf-dev] State of the 119 distribution part|
Did anything odd happen to the CVS? I could not commit my changes because CVS complained that my version is not on the server, so I checked out the distribution plugin again and my changes are gone. > Well, it could/rather look for all container type descriptions that > return the IRemoteServiceContainerAdapter classname to > ContainerTypeDescription.getSupportedAdapterTypes()...and then create > instances that don't already exist...and then register with them. Yes, that's probably the way to go. I managed to get one step further with my service publication by manually creating the container in the test case. > Yeah...it frankly still seems like strange motivation to me > frankly...since not knowing/requiring anything about the properties of > the distribution software (modulo intents) means the service itself > (performance/reliability) will/may not have certain > characteristics...but that's another discussion. Yes. But I guess that's what intents are good for. These constraints are by nature high level. If they are not, why bothering with using something generic like ECF or 119 and not directly coding against the API of a specific distribution software known to have the desired properties. > Ok...all relevant ECF providers can respond to distribution > registrations...and we can use the getSupportedAdapterTypes to decide > on > relevancy. I'll make sure existing providers define this information > on > the ContainerTypeDescriptions. One thing that crossed my mind: We should be able to get a unique identifier for each registered service that can be used to pass it to the discovery provider. I think, currently the IRemoteServiceRegistration only returns a container ID but not a "service id". Looks like we have to extend the API here. Cheers, Jan.
Back to the top