> > While `info` takes object ids one at a time, this creates overhead when > > making requests to a server so `remote-object-info` instead can take > > multiple object ids at once. > > I am not sure if the above is desirable---doesn't it make the > protocol (i.e. the requests the invoker of "cat-file" needs to > prepare) unnecessarily complex? If we have "buffered" mode, the > implementation can collect and batch requests and talk with the > other side in a single communication with the other end, no? I'm a little bit confused as to what you are suggesting here, in terms of how a user would want to call this command. Are you saying this functionality should only work in "buffered" mode? Or are you saying that `remote-object-info` should only take one object id at a time, and in buffer mode, those requests are batched together? > > > In --buffer mode, this changes to: > > > > - Receive and parse input from user > > - Store respective function attached to command in a queue > > - After flush, loop through commands in queue > > - Call respective function attached to command > > - Set batch mode state, get object info, print object info > > So, the existing buffered mode is poorly designed, in other words. > Isn't this something we can fix for performance without affecting > the existing callers? Much of the existing cat-file code seems to be designed around taking in one object/command at a time, and --buffer can be thought of as a wrapper around that preexisting code that simply stores a queue of commands rather than running them immediately. I think the existing buffered mode is well designed -- this part of the commit message is to explain why at some point I need to preprocess what is in the buffer
