| 1 |
On Tue, May 31, 2005 at 02:38:58AM -0400, Alec Warner wrote: |
| 2 |
> I was looking at Transport code last night and I noticed it only |
| 3 |
> supported HTTP/HTTPS/FTP, which I thought was kind of limited. Thoughts |
| 4 |
> on merging the Sync code in with Transports, having the transport lib |
| 5 |
> covering all...well..file transport code within portage? The Rsync code |
| 6 |
> is strikingly similar, and I was thinking of adding scp as well so |
| 7 |
> people have a lot of options. |
| 8 |
> |
| 9 |
> Thoughts, objections...donuts? |
| 10 |
I like cheese. ? |
| 11 |
|
| 12 |
scp doesn't support resume, so it differs from existing transports if |
| 13 |
added. For merging of sync and transports, transports is specifically |
| 14 |
single file network io requests, sync can mangle multiple files. |
| 15 |
|
| 16 |
Dunno, possible. |
| 17 |
Honestly sync and transports could use a mild set of touch ups, |
| 18 |
although not sure about collapsing/combining the sync/transports bit. |
| 19 |
Reasons for it, aside from having a few more protocols able to be |
| 20 |
handled? Hadn't thought about the possibility of supporting cvs for |
| 21 |
SRC_URI- that would be nifty, although would need a way to specify a |
| 22 |
required atom for protocols (if this cpv has cvs://blar in it, it |
| 23 |
requires dev-util/cvs, or preferably a virtual should dev-util/cvs |
| 24 |
ever move... |
| 25 |
~brian |
Archives