Hi Jeff,
Jeff McAffer wrote:
This seems like an interesting
approach
to implementing an OBR-like client. Note that OBR is not a transfer
protocol but rather more a discovery and selection mechanism. It
uses metadata that follows the proposal in OSGi RFC 112 and uses that
information
to select and then download the required/requested information.
Related
to this is an indexing tool that generates the required metadata (David
Williams has been running that on the Callisto update site for example).
To be clear, I am not pushing OBR
per
se. What I like about it is that it is repo independent, small, simple
and it exists. Going forward I hope that the Eclipse provisioning
story will be expanded to include the kinds of usecases discussed here
(including the need to accomodate various repo formats).
Did I miss something wrt the
function
that the ECF code provides?
I'm not sure. I wasn't proposing that ECF provides an OBR
implementation, only that it could be used to provide a transport
independent (and therefore repository protocol-independent) access to
file transfer. I agree that's clearly just one piece to a full OBR (or
equivalent) client...along with discovery and selection and probably
other things.
But if an OBR (RFC 112)-like client for Eclipse is created/used, it
seems it would be helpful to use a transport independent transfer API
for the implementation of such a client (i.e. allowing/supporting more
protocols for the 'Bundle-SourceURL' and 'Bundle-UpdateLocation' with...e.g. maven://foo.lala.com/artifactid).
It's also possible that ECF's discovery API (org.eclipse.ecf.discovery
with zeroconf for one provider) could also be useful here, but I don't
yet know anything about how the OBR discovery approach works, so I
don't know that to be the case.
Scott
Jeff
Hi Jeff and all,
Jeff McAffer wrote:
couple of notes.
- OBR was just one idea. The main benefit is that it is repo agnostic
so the current orbit download site for example would serve just fine as
a repo. Similarly, an update site or maven repo would alos work...
One thought/immodest proposal: ECF is finishing up a 'filetransfer'
API (org.eclipse.ecf.filetransfer) that supports asynchronous file
retrieval.
It's similar to KDE's KIO (in concept anyway). We use now us
Apache httpclient 3.0.1 for http/https (soon from Orbit) and
java.net.URLConnection
for ftp, file, bittorrent (EPL impl done and soon to be added) and any
others registered via URLStreamHandlerService.
It would/will be simple to add maven repo (or other repos)...and that's
on the docket.
This API with appropriate providers could easily be used for fetching
from
custom/other repositories as well and provide some isolation of the
client
and UI code from the underlying transport/impl.
Scott
ECF: http://www.eclipse.org/ecf
API javadocs: http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
|
