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

[Thomas Hallgren <thomas@xxxxxxx>]

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
>