Jeff King <[email protected]> writes: > I.e., I think the conversation ought to be more like: > > Server: I support packfile-uris X, Y, Z. > > Client: Great. I'll use URIs X and Z. > > Server: OK, here's your pack, minus any objects I know are in X and Z. > I'll send you the objects from Y as normal.
I agree with the overall direction, but I am afraid that the server advertisement may have to become a lot more complex. For example, are you assuming in the above example that X, Y and Z are not overlapping? Or perhaps X is the whole repository that is quick to access only from European clients, while Y and Z combined have the same set of objects that are meant for our Asian friends. IOW, the server may expect that the client would say one of three "there is nothing I can use then", "I am happy with X and won't use Y and Z" or "I'll use Y and Z then, without X", and no other combinations like "I'll use X and Z" may make sense. > And then the client is free to pick and choose. The initial server uri > list can come in the capabilities list, or it can be a separate request > once the client sees the server supports packfile-uris and wants to ask > about them. We may need some way for the server to group the uris so > that the client knows which ones are alternates of each other (and which > ones are needed to make a complete set). I guess what I am saying is that it is not so clear how we can present the server offered URIs to the client in such a way that the client (either mechanically, or consulting the human) can make a useful choice,
