Community
Participate
Working Groups
In ECF, it's possible to get at the list of supported transports. Consider adding a console command 'provlt' to list transports. A patch is provided.
Created attachment 61214 [details] org.eclipse.equinox.prov.console.patch
It seems a bit odd to add this to the provisioning console, since it doesn't even touch or involve provisioning code. To me the fact that certain parts of the provisioning code make use of ECF is just an implementation detail.
What is the plan in provisioning to support pluggable transport? Right now I only see a RequestHandler in the provisioning code for transporting. Do we need to create an API in provisioning to allow pluggable transports (and a way to query for support transports) and have ECF plug-in? If so, open a separate bug and maybe we can prototype something.
Currently, RequestHandler is the main transport API. Repository implementations can implement this directly if they want to take care of transport themselves. There is a subclass, ECFHandler, that implements transfer using ECF. So, clients currently have the option of providing their own RequestHandler, or plugging into ECF and providing a transport at that level. I'm sure the transport story will need some more fleshing out, so ideas are welcome. ECF is great, but there will be repositories that don't want to be tied to ECF.
I would suggest that before a new API for pluggable transports is designed, that people consider just using and/or modifying/enhancing the ECF 'identity' plugin (org.eclipse.ecf.core.identity). One of the main purposes of the Namespace class and associated extension point, for example, is to support the adding of transports programmatically or declaratively and the querying of supported transports as demonstrated by Chris' patch https://bugs.eclipse.org/bugs/attachment.cgi?id=61214. The existing ECF API may not be perfect for all requirements implied by provisioning/pluggable transports, but it is mutable to meet other expressed needs, small in code size, no dependencies other than on JRE 1.4, EE/CDC 1.0, org.eclipse.equinox.common, and has been working well for the rest of ECF for some time. And, we don't yet have backward compatibility requirements.
should requesthandler's be tied directly to repositories, or should there be a pluggable way for repositories to query for handlers? ECF has a supported way to add handlers via the urlStreamHandlerService extension point. So you can effectively add handlers via specialized urls.
Closing. It doesn't make sense to add ECF console support to the p2 console.
