[MERGE] Transport support for pack repositories

[Robert Collins]

On Tue, 2007-08-07 at 22:50 -0400, Martin Pool wrote:
> Martin Pool has voted resubmit.
> Status is now: Resubmit
> Comment:
> Adding a way to more clearly do multiple reads or writes to a file 
> sounds good.
> 
> I think these should act more like regular python file objects unless 
> there is a good reason to do otherwise.  That would mean returning an 
> object on which you can call write, rather than just the write-like 
> method itself.  That doesn't oblige us to support all the other methods 
> as well as write but it leaves room for change in the future.

There is a good reason to do otherwise. Streaming is a much smaller
interface than seeking, appending, etc. Its not significantly harder to
make this return a 'file' object with a write method in the future, but
it is harder to explain that 'its really not a file' today - and I don't
think we will want it to become a file.

> I would then give that object a close method, rather than calling 
> close_file_stream() on the transport.  It seems like that would also 
> dispense with the need for a global _file_streams.

No, it wouldn't. The global is for synchronisation, not for implementing
close().

> Also one might conceivably want to have read-mode file streams

Transport.get()

> , or 
> read/write

This really doesn't fit with the use case that is driving having a
streaming interface.

> , and it seems strange that open_file_stream would give you 
> one you can only write to.  So again I'd suggest being more like python 
> and having it take a parameter that can be 'r', 'w' or whatever.  It's 
> fine with me if the only value that's accepted for now is 'w'.
> 
> Then this could be unified with get, which returns a readable file-like 
> object.  That's a poor name for it, but get()'s callers can be changed 
> to call this.

In short, what you are asking for is to offer regular unix file
semantics over all our transports. But thats really hard to do
efficiently or well, and thats why we have readv(), rather than
transport.get('foo').readv((list)).

I think its better to keep the requirements put upon the transport layer
distinct and not mix them up with different scenarios. We typically
either read the entire thing. Or we read some parts (readv), or append
data (append), or provide the entire data (put_*), and now - for packs
only - provide data incrementally.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070808/30246e09/attachment.pgp