[
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 Thomas,
Thomas Hallgren wrote:
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.
My apologiesinadvance, but the best current documentation for the file
retrieval is in either the
a) test code. See here for project set file for everything including
tests: http://www.eclipse.org/ecf/dev_resources.php
b) the javadocs for the IRetrieveFileTransferContainerAdapter class:
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/filetransfer/IRetrieveFileTransferContainerAdapter.html
I'm currently looking at writing a OBR provider for Buckminster. I
downloaded the source and at first glance it seems fairly trivial.
Cool. I would like to talk with you about this effort.
Are you suggesting using ECF to discover and download components? If
so, we must talk about synergies :-)
ECF's discovery API (as implemented on zeroconf) could certainly be used
to discover (and then using file transfer API to download/install/run)
components/bundles...that sounds very interesting/exciting.
Scott
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
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
