[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
