[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orbit-dev] Invitation: Orbit conference call (Jan 9 11:00 AM EST)
|
Hi Scott,
This transfer independent protocol seems interesting. I think we might
incorporate it in Buckminster somehow. We could easily slot it in under
our current Maven provider and also use it for the URL provider. Can you
provide a link to more info? I scanned your wiki (very quickly) but I
didn't really know what to look for.
I'm currently looking at writing a OBR provider for Buckminster. I
downloaded the source and at first glance it seems fairly trivial.
Are you suggesting using ECF to discover and download components? If so,
we must talk about synergies :-)
Kind Regards,
Thomas Hallgren
Scott Lewis wrote:
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
*Scott Lewis <slewis@xxxxxxxxxxxxx>*
Sent by: orbit-dev-bounces@xxxxxxxxxxx
01/10/2007 03:16 PM
Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
To
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject
Re: [orbit-dev] Invitation: Orbit conference call (Jan 9 11:00 AM EST)
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
------------------------------------------------------------------------
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev