Re: [orbit-dev] Invitation: Orbit conference call (Jan 9 11:00 AM EST)

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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?

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